Re: Some concerns on the current situation on Go packaging

2022-09-28 Thread Maxim Cournoyer
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

Some concerns on the current situation on Go packaging

2022-09-27 Thread Gabriel Arazas
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

Re: Go packaging

2017-10-10 Thread ng0
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

Re: Go packaging

2017-10-10 Thread 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

Re: Go packaging

2017-10-05 Thread Ludovic Courtès
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

Re: Go packaging

2017-10-05 Thread Leo Famulari
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

Re: Go packaging

2017-10-04 Thread Leo Famulari
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

Re: Go packaging

2017-10-03 Thread Pjotr Prins
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

Go packaging

2017-10-03 Thread Leo Famulari
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