> 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!

> 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.

Misunderstanding?

> 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?

> > - gx retrieves the deps over IPFS: how important is this?  Should we do
> >   the same?  What about using "gx"?  We could also implement a new
> >   "gx-fetch" method fully written in Guile.
>
> In Guix dependencies are listed statically in the ‘inputs’ fields, so I
> suppose we have to run it once to retrieve that list and then “encode”
> it as ‘inputs’, no?

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

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

- 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.

Makes sense?

-- 
Pierre Neidhardt
https://ambrevar.xyz/