Edits and updates

• (advSORRYance) removed hard newlines
• richer prior art section (formatting, info about Nixpkgs go support)
• better open questions formatting
• added some notes/pointers about how Debian packages Go applications (spoiler: they populate a directory in /usr/share and access it via GOPATH).
• en{biggened,riched} the FreeBSD notes
• looks like Nixpkgs now downloads go dependencies at build time using go mod download.

Intro

I'm thinking about putting together support for go-based packages. Going forward, I believe that most go applications will use modules to manage their dependencies so my initial plan is to focus support on applications that either:

1. use modules and vendor their dependencies; or
2. use modules but do not vendor their dependencies.

I plan to provide generic implementations of the basic phases that would be useful to both cases and tooling that would help package authors define and fetch resources in the second case.

I think that there is not sufficient commonality to the ways that "pre-modules" applications manage their dependencies for effective automation. Such applications still might be able to take advantage of generic build steps.

Prior art

There seems to be two approaches to this:

• using go list -m json (and variations); and
• running go mod vendor and parsing the resulting vendor/modules.txt file.

Other projects include:

• the FreeBSD ports tree has nice prior art with nice documentation for this approach, including a tool (modules2tuple) to help port authors manage their dependency declarations.
  See the section of the FreeBSD Porters Handbook entry that encloses their example of "Creating a Port for a Go Modules Based Application" for details about FreeBSD ports and Go.
• Homebrew's go support is simpler; as far as I can discover they just provide a helper that unpacks resources into a GOPATH style tree.
• Ah, for Go applications that use modules, Nixpkgs now grabs the dependencies at build time. See docs for buildGoModule and the PR that introduced it. That said, these tools still exist:
  • vgo2nix automates Nixpkg creation for Go applications that use modules
  • go2nix automates Nixpkg creation for pre-{dep,modules} Go applictions
  • the Nix Golang Demo project's README includes a summary of how Nix deals with Go and modules, including interesting links.
• Debian....
  • @jessieduffield has a rep/project aimed at packaging lazygit for debian. It includes several useful pointers to Go related Debian documentation.
  • While I haven't [yet] found an explicit statement, this comment from the go-team's docs strongly suggests that they're building in GOPATH mode.

    All files should be installed into /usr/share/gocode/src/, which corresponds to $GOPATH/src

Open questions

• How to deal with the volume of resource declarations. E.g. the current release of Hugo has nearly 70 top level dependencies, that result in over 300 dependent packages (in the Go sense) that are supplied by 80+ modules/repositories. If each new release updates its 80+ resources then the hugo package would quickly become hundreds of lines long.

  Does Spack (this might just be a naive Python question...) have a mechanism for including other files in the packages directory? It would be reasonably tidy to use a series of deps-X.Y.Z.py files to record the require resources for the individual releases.

Feedback?