Pierre Neidhardt <mail@ambrevar.xyz> skribis:

>> FWIW Pierre-Antoine (who was working with me as an intern on Guix-HPC)
>> has given me the last revision of the gopkg importer, which I’m planning
>> to include soon.  It might be useful to you!
>
> Absolutely!  Could you share the code now so that I can start using it?  Thanks!

Attached!  Leo reviewed an earlier version of this code already.

>> This seems to be the same for all Go packages: they specify the exact
>> commit of each of their dependencies, AIUI.
>
> No, Go programs typically refer only to repositories, not to their commit.  This
> is precisely why it's a problem.  Golang's dependency management was not very
> well designed I'm afraid.

I was referring to the “gopkg” way of handling dependencies (with those
“.toml” files), which is what the importer implements.

Now, there are apparently several dependency management tools in use, so
I guess my comment only applies to the gopkg way, but I’m not well
versed into Go.

>> In practice it may be that upgrading will often be fine, but it does
>> mean that every time we upgrade a Go package, we have to build
>> everything “guix refresh -l GO-PACKAGE” reports to make sure.
>
> Yup, but it's also the case with any other package, isn't it?

Of course :-), but I mean it’s even more important here due to the way
upstream handles this (no semantic versioning and in fact, no releases.)

> Sorry, I meant "ipfs-fetch", so we might be talking about different things :p

Oh OK.  ‘ipfs-fetch’ surely makes a lot of sense.  (What makes even more
sense is substitutes over IPFS!)

> - Network: it would be nice to be able to retrieve packages over IPFS.  We can
>   do this without IPFS, just like "gx" does.

Sure.

> - Importer: I don't know how Pierre-Antoine retrieves dependencies, but
>   technically it's enough to download the package and run some "go ..." command
>   to list deps.  In the case of go-ipfs (and possibly other Go packages using
>   gx), we can only list the deps with "gx deps...".  Note that in both bases the
>   package does not have to be built, if I'm not mistaken.

The importer parses ‘Gopkg.toml’ files, which may or may not be useful
for IPFS and its dependencies.

Ludo’.