Re: Go packaging

[Pjotr Prins]

On Wed, Oct 04, 2017 at 10:22:25AM -0400, Leo Famulari wrote:
> That package.json file is not a standard thing in the Go world.
> I've found that Go applications use a variety of dependency manifest
> formats, or just use Git submodules.

Guix is a good thing then :). Also it means that they don't really
enforce a dependency graph. How can you enforce something if you have
many implementations? The enforcement is only at the single package
level.

> Rather, I think we should have a special go-package procedure, used in
> the inputs field of the calling application, which would build the
> relevant library modules of the correct Git commit. Does that make
> sense?

Yes. Since you can do a 'go build' I think it is possible to do this
in a traditional way. It sucks that GO has so many small dependencies
(similar to the node mess). But maybe we can import them somehow. Does
the build tool show the graph?

It is interesting that different packages have different git checkout
dependencies (so different hash values for the same package go-ssl or
whatever). For developers this is great because users end up with the
exact same dependency graph. But for Guix I think we can ignore this.

It is what we are doing today. It is easy to create a deployment
environment in Guix that was never tried before. Therefore, we also
don't really care. We just provide the latest and see if that works.
So, I suggest to import just one version of go-ssl and cross fingers
it works. If it doesn't - well then it gets a bit harder and we'll
have to deal with multiple versions.

> > We ought to have a look at how Nix packaged Go builds because they are
> > already have a solution. Be interesting to see if they found a way to
> > compile packages 'greedily', the way Python does it.
> 
> I looked at their build system itself a few weeks ago when I was still
> learning how Go compilation works. I agree, it would be fruitful to see
> how they handle the issues I've raised here.

Any update?

Pj.


--