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
