* Some concerns on the current situation on Go packaging
@ 2022-09-27 15:51 Gabriel Arazas
2022-09-28 14:27 ` Maxim Cournoyer
0 siblings, 1 reply; 2+ messages in thread
From: Gabriel Arazas @ 2022-09-27 15:51 UTC (permalink / raw)
To: guix-devel
Hello! I'm a bit concerned about the current situation of packaging of
Go applications in Guix.
Go modules also use semantic versioning [1] similarly to Rust packages.
In Guix, some of the Rust packages are packaged with different versions
[2]. This is nice (and tedious) as applications are more likely to work
as intended.
However, there doesn't seem to be documented practice of packaging
different versions for Go applications. The lack of such section from
the manual also gives an additional impression unlike Rust packaging
[2]. I don't know much examples that can be found committed in Guix repo
but this makes adding Go applications to be more of a pain. I mean
packaging Rust apps is also a pain as much as packaging Go apps (at
least in my experience) but at least there are some explicit guidelines
you can follow which is also present when exploring the code.
For example, I'm about to package gum [3] and it needs a different
version of termenv (some commit after 0.11.0) compared to the packaged
version in Guix (0.8.1). I'm very tempted to add a different package for
it with a different version (which is thankfully easy to add).
In the long term, I'm more 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/version-numbers
[2]:
https://guix.gnu.org/manual/devel/en/html_node/Rust-Crates.html#Rust-Crates
[3]: https://github.com/charmbracelet/gum
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Some concerns on the current situation on Go packaging
2022-09-27 15:51 Some concerns on the current situation on Go packaging Gabriel Arazas
@ 2022-09-28 14:27 ` Maxim Cournoyer
0 siblings, 0 replies; 2+ messages in thread
From: Maxim Cournoyer @ 2022-09-28 14:27 UTC (permalink / raw)
To: Gabriel Arazas; +Cc: guix-devel
Hi Gabriel,
Gabriel Arazas <christiangabrielarazas@gmail.com> writes:
> Hello! I'm a bit concerned about the current situation of packaging of
> Go applications in Guix.
>
> Go modules also use semantic versioning [1] similarly to Rust
> packages. In Guix, some of the Rust packages are packaged with
> different versions [2]. This is nice (and tedious) as applications are
> more likely to work as intended.
>
> However, there doesn't seem to be documented practice of packaging
> different versions for Go applications. The lack of such section from
> the manual also gives an additional impression unlike Rust packaging
> [2]. I don't know much examples that can be found committed in Guix
> repo but this makes adding Go applications to be more of a pain. I
> mean packaging Rust apps is also a pain as much as packaging Go apps
> (at least in my experience) but at least there are some explicit
> guidelines you can follow which is also present when exploring the
> code.
>
> For example, I'm about to package gum [3] and it needs a different
> version of termenv (some commit after 0.11.0) compared to the packaged
> version in Guix (0.8.1). I'm very tempted to add a different package
> for it with a different version (which is thankfully easy to add).
What I would do here is update termenv to latest, and try to use it with
your new gum packaging. Chances are it'll work. You'll want to rebuild
the other packages affected by the update, which you can 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 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?
We favor using the latest version of everything, as long as there is a
strong reason not to (e.g., a test suite failing or the software not
compiling). This means less packages definitions, which should be
easier to maintain. For Go, I think it'd make sense to carry the latest
version of a package as well as any previous *major* version that may be
*required* by other packages.
I hope this helps,
Thanks,
Maxim
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-09-28 15:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-27 15:51 Some concerns on the current situation on Go packaging Gabriel Arazas
2022-09-28 14:27 ` Maxim Cournoyer
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).