Ludovic Courtès transcribed 0.4K bytes:
> Leo Famulari skribis:
>
> > I think we should do "go-$upstreamname" instead. Golang is not the name
> > of the language, but rather the domain name (go.org was apparently not
> > available), and a term that has been adopted by the community. But, it
> > w
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
Leo Famulari skribis:
> I think we should do "go-$upstreamname" instead. Golang is not the name
> of the language, but rather the domain name (go.org was apparently not
> available), and a term that has been adopted by the community. But, it
> would be good to save 4 characters here.
I’m all for
On Tue, Oct 03, 2017 at 11:15:04AM -0400, Leo Famulari wrote:
> Based on my work creating a go-build-system and packaging a non-trivial
> Go application [0], I want to start a discussion on how we can
> efficiently package Go software in Guix.
Another question, which is bikesheddy, is how to name
On Wed, Oct 04, 2017 at 06:19:18AM +0200, Pjotr Prins wrote:
Thanks for your comments, Pjotr!
> Thanks Leo for the explanation. Now I understand why Go programs, such
> as the IPFS implementation, have so many dependencies...
Yes, so many. As for transitive dependencies... well, I probably won't
Thanks Leo for the explanation. Now I understand why Go programs, such
as the IPFS implementation, have so many dependencies... What I
understand now is that packages get built 'lazily' and there is really
no way to force a build - other than running the target software. I
noticed the hash values i
