Golang packaging, following up Rust conversation on packaging

[Sharlatan Hellseher]

Hi Guix,

After reading the thread:
How to move forward about Rust? antioxidant, cargo2guix, etc.
 <https://lists.gnu.org/archive/html/guix-devel/2025-02/msg00417.html>

I've faced with the fact that Golang had a very close approach during
compilation as Rust, where each package defined in Guix is not reusable
as library but re-compiled from scratch with provided source.

Some upstream news:
- Go Toolchains, starting from go@1.21 https://go.dev/doc/toolchain
- Go workspaces (aka monorepo), starting from go1.18
  https://go.dev/blog/get-familiar-with-workspaces
- Go.mod https://go.dev/doc/modules/gomod-ref
> The go directive sets the minimum version of Go required to use this
> module. Before Go 1.21, the directive was advisory only; now it is a
> mandatory requirement: Go toolchains refuse to use modules declaring
> newer Go versions.
- Golang supports way to many environment variables than current
go-build-system is aware of
https://raw.githubusercontent.com/golang/go/b38b0c0088039b03117b87eee61583ac4153f2b7/src/internal/cfg/cfg.go

Some long waited discussions to bring go.mod aware build system and
re-usable builds:
- [PATCH 0/3] go-build-system and GOPATH improvements
  https://issues.guix.gnu.org/50227
- [PATCH 0/1] Fix cross-compilation of packages that use go-build-system
  https://issues.guix.gnu.org/51981
- [PATCH 2/4] guix: add go module aware build system
  https://issues.guix.gnu.org/74374
- Golang build cache and content-based staleness in Guix
  https://issues.guix.gnu.org/32919

Simple questions to ask:
- is it save to build package A which requires package B@1 but with B@2
- is it save to build package A which requires package B@2 but with B@1
- is it save to build package A which requires go@1.18 with go@1.21+
- is it save to build package A which requires go@1.23 with go@1.21
- is it save to build package A which go@1.21 and deferent toolchain
version (something new here...)
- how to re-use the builds and save some N+ time and M+ energy on
  compilation
- how to proper package multi modules repository, it's hard right now
- if we follow the go.mod way, do we need to package each possible
version to cover any combinations

From my experience, go.mod is bumped just blindly on cron with services
provided by GitHub or third parties and does not affect too much the
compilation, until the upstream changes API dramatically; unit tests
block this type of regression, that why ""#:tests? #t" is pleasurable
with "./..." option, which is default now on go-build-system

I might deep dive into GCD and prepare a fresh go-build-system
adjustments proposal covering most of the concerns

---
Oleg

signature.asc
Description: PGP signature