all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Pjotr Prins <pjotr.public12@thebird.nl>
To: Leo Famulari <leo@famulari.name>
Cc: guix-devel@gnu.org
Subject: Re: Go packaging
Date: Tue, 10 Oct 2017 18:46:08 +0200	[thread overview]
Message-ID: <20171010164608.GA6957@thebird.nl> (raw)
In-Reply-To: <20171004142225.GA2547@jasmine.lan>

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.


-- 

  reply	other threads:[~2017-10-10 16:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 15:15 Go packaging Leo Famulari
2017-10-04  4:19 ` Pjotr Prins
2017-10-04 14:22   ` Leo Famulari
2017-10-10 16:46     ` Pjotr Prins [this message]
2017-10-05 12:16 ` Leo Famulari
2017-10-05 13:41   ` Ludovic Courtès
2017-10-10 17:21     ` ng0

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171010164608.GA6957@thebird.nl \
    --to=pjotr.public12@thebird.nl \
    --cc=guix-devel@gnu.org \
    --cc=leo@famulari.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.