[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#44178] [PATCH] Create importer for Go modules

From: JOULAUD François
Subject: [bug#44178] [PATCH] Create importer for Go modules
Date: Fri, 19 Feb 2021 15:51:02 +0000


I will send a v3 of the patch very soon which I hope will be mergeable.

It is still very experimental and I noted it as such in documentation.

I had problems with the hash in origin which did not work as expected. I
prefered to drop this completely for now and replaced it by a full 0
placeholder. At least it is consistently and conspicuously bad. I have a
working version of something which download git repo and generates guix
hash for it but I'd rather to push this in a subsequent patch as it is
very rough for now.

On Sun, Jan 31, 2021 at 05:23:59PM +0100, Ludovic Courtès wrote:
> JOULAUD François <> skribis:
> > I found that some go.mod out there uses quoted string
> > which our ad-hoc parser don't know how to parse. cf.
> Your call; if it’s an infrequent problem, we could commit it and leave a
> FIXME in the code.  We could also use guile-yaml (or maybe some Go
> code?) to parse it correctly.

I found a way to work around the problem.

Indeed using "go mod" to parse the go.mod file could perhaps be easier
and have been explored[1].

It works for now with the ad-hoc parser. Let's revisit the choice later
if neeeded.

> > Apart from that I don't know how to add guile-lib to the dependencies of
> > Guix (in order to use htmlprag). Help needed.
> So ‘xml->sxml’ isn’t good enough?  (If we can avoid the guile-lib
> dependency, the better.)

HTML is not well-formed XML (and the hopes given by XHTML have faded)
so no, xml->sxml is unfortunately not good enough.

> To depend on Guile-Lib, you would:
>   1. Add it to (guix self) — this is the code used by ‘guix pull’;
>   2. Add it to the ‘inputs’ field of the ‘guix’ package;

Done 1 and 2 in the patch. Mainly by copy-paste without understanding
anything. I hope it will work.

>   3. Maybe add a configure check in ‘’, though it would be
>      best if we could arrange to make it an optional dependency.

I did not touch to which is a strange beast to me. Hope that
for optional dependency (only used in "guix import go") it is sufficient.

> > I tested it recursively with (which was one
> > of those with the most dependencies I found) and it mostly works.
> Yay, sounds promising!

Promising but not there. I have now several recursive dependencies
between generated packages I must investigate.

Still, 234 package definitions generated on one recursive import (even
if I had to retry because of intermittent failure of fetching from, so Yay!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]