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