Some concerns on the current situation on Go packaging

Some concerns on the current situation on Go packaging

[Gabriel Arazas]

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

Re: Some concerns on the current situation on Go packaging

[Maxim Cournoyer]

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