get a list via
`./pre-inst-env guix refresh -l termenv`. I think since this package is
at 0.11.0, it hasn't yet reached a stable release (1.x.x).
> In the long term, I'm more concerned about adding and maintaining of
> these applications. I thought I should point them out an
concerned about adding and maintaining of
these applications. I thought I should point them out and hopefully get
the community to reach to a consensus for Go packaging. Or is there
already some initiatives (or a consensus or even some discussions) that
I missed?
[1]: https://go.dev/doc/modules
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
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
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
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
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.
Go software is developed rather differently from most of what we
package, and I think our package abstraction does not