Hi Oleg (and the go-team),

As I have spent some time with the go-build-system, I have a couple of
extra suggestions/ideas. Obviously, as the person suggesting these
changes, I would be more than happy to help implement them. This will
unfortunately be a rather lengthy and very information-dense email due
to the specifics of the build system, so here goes:

It seems originally the intention of the Go build system was to have
Guix packages per module. For example, to package
"golang.org/x/net/ipv4" as a separate Guix package
`go-golang-org-x-net-ipv4`, we would set `unpack-path` to
"golang.org/x/net/ipv4" and `import-path` to the base of the Git
repository, i.e. to "golang.org/x/net". See for example the comments in
"guix/build/go-build-system.scm":

--8<---------------cut here---------------start------------->8---
;; In general, Go software is built using a standardized build mechanism
;; that does not require any build scripts like Makefiles.  This means
;; that all modules of modular libraries cannot be built with a single
;; command.  Each module must be built individually.  This complicates
;; certain cases, and these issues are currently resolved by creating a
;; file system union of the required modules of such libraries.  I think
;; this could be improved in future revisions of the go-build-system.
--8<---------------cut here---------------end--------------->8---

There is also a note in the TODOs:

--8<---------------cut here---------------start------------->8---
;; * Remove module packages, only offering the full Git repos? This is
;; more idiomatic, I think, because Go downloads Git repos, not modules.
;; What are the trade-offs?
--8<---------------cut here---------------end--------------->8---

I agree with the statement that this split is not idiomatic. To answer
the question, I see at least several downsides of our current situation:

- Cross-module dependencies for the same overarching Go package/tree are
only specified in the files they are used in, not in "go.mod". To
clarify my use of "Go tree", "golang.org/x/net/ipv4" and
"golang.org/x/net/ipv6" would belong to the same "golang.org/x/net"
tree. There would be no feasible, systematic way to figure out all
dependencies for a large enough package, besides failing to build and
adding missing dependencies on the fly.
- Since there is no internal versioning inside a single Go tree, all
modules of a single Go tree would need to be upgraded together or you
might face an unexpected breakage.
- The module-based naming scheme has not been followed consistently. I
think this is mainly due to Go importer not working in this way. This
led to some annoyances when I was packaging some Go package, since I
assumed a module was included when in actuality it was not (for example
`go-github-com-kylelemons-godebug`). I have also noticed some duplicate
packages, such as `go-etcd-io-bbolt` and `go-go-etcd-io-bbolt`.

From what I can tell, the idiomatic way would be to append "/..." to the
import path, both for `go install` and for `go test`. This would
recursively install any binaries and test all packages.

Unfortunately though, neither change can easily be done incrementally.
Quite a few Go package builds are missing inputs and this is not caught
by the current build system. I have started adding some missing inputs
here and there, but from my point of view, we cannot reasonably proceed
without a dedicated go-team branch.

Some additional and miscellaneous suggestions in no particular order:

- With Python I can run something like `guix shell python python-pandas`
and immediately start development. With Go this is not as simple and at
least some environmental variables need to be set beforehand. I had to
figure out how this works from go-build-system.scm, so I think it would
be good to explicitly document how to use Guix for local Go development
for anyone who wants to give it a try.
- I find the build phase hard to debug with the current `go install`
flags. The combination "-v -x" that is set by default gives way too much
information in my opinion.
- Some builds fail due to the default `go test` timeout of 10 minutes.
For example, I was not able to build go-etcd-io-bbolt locally at all. I
would suggest we turn off the timeout to ensure local reproducibility.
- As far as I can tell, there is no way to skip single tests with the
current build system. This is easy to implement, because `go test` comes
with a "-skip" flag. There is no equivalent of `build-flags` for the
check phase yet, so I think it would make a lot of sense to add a
`test-flags` parameter.

Best wishes,

Troy