Building Go programs with Nix flakes

I think there's two angles to come at gomodule2nix from, basically. You might either be

  1. someone who is already a Nix user, figuring out if/how you want to build a Go package you have for use with other Nix tooling; or
  2. someone who is already a maintainer of a Go package, trying to decide if/how you want to offer Nix integration to your users/contributors

The blog post is by someone in the first group, seemingly aimed at the same. This would apply if you/your org

  - are NixOS users
  - use Nix in CI/CD
  - use Nix to create/deploy server images
  - use Nix to create/deploy container images
  - use Nix to provide reproducible development environments across different projects written in different programming languages

In that case, you're trying to slot an out-of-tree Go package (i.e., not already one of the 80,000+ packages in Nixpkgs) into existing infrastructure where packaging via Nix, one way or another, is already the norm. This is probably something you'd do for in-house packages, but you might also want to do it for vendor-supplied packages or oddball F/OSS that hasn't made it into Nixpkgs yet. In that case, I don't think gomod2nix really adds undue complexity over any alternatives.

Here's an answer more tailored towards that second group, Nix-curious maintainers of Go packages. You might want to add a Nix flake to your existing Go project if:

  (a) your project uses CGo or any foreign libs via FFI
  (b) you have or would like to have users/contributors who are new to Go but not to Nix
  (c) your application needs to communicate with external programs at runtime to do anything useful (e.g., it's a microservice)
  (d) you would like to provide users/contributors ready-to-use debugging, monitoring, or editing tools

For (a), (c), and (d), adding a Nix flake essentially helps you manage the otherwise hidden complexity of having users set up external parts of your application's build and runtime environments. Those could be 'native' C dependencies or other applications that are expected to run alongside your Go code. In these cases, you want to compare the complexity of using gomod2nix to maintain a Nix flake to the complexity of maintaining one or more containers and some orchestration, the complexity of automation for setting up the external tools in the environment, or the complexity of documenting/guiding users through manual setup of the external or 'foreign' parts of environment setup.

Case (b) for Go-first users is kind of similar to the general appeal for Nix-first users, but with less commitment. Nix has uniform ways of managing ephemeral applications that don't permanently live on your usual PATH. They're awesome for trying out new software in a non-committal way. Adding a Nix flake to your project is thus morally a bit like providing a Homebrew recipe: it makes it easy to run or install your software via a general tool that prospective new users may already have and be willing to use. Could prospective new users 'just' use `go install` to install your little CLI app instead of using a Nix package? Sure! Are they likely to prefer to do that if they're not themselves to developers? Maybe not.

In the Go-first use case, I think the sensible complexity considerations to make are the cost (to you) of maintaining the flake. The problems to consider would be whether or not it will divide your users/contributors into groups using different toolchains (it won't, since it reuses your existing Go übertool's resolved dependencies, and whether users/contributors who don't plan on using that integration would nonetheless be confronted with its complexity (they won't; not using the flake is free and this tooling doesn't modify any non-Nix files). So that really just leaves the question of whether you think any potential users/contributors will enjoy being able to leverage your package via Nix, and how much effort it will take from you to offer them that.

If you think none of your current or potential users/contributors use Nix, then this probably is an increase in complexity for you with no payoff for you. But otherwise, it might be worth doing or involve less complexity than alternative solutions.

Accidental implementation of an interface is a footgun at best. These are contracts that should be explicit and deliberate. “Write” doesn’t always mean “I/O,” for example, but if you have data for which “Write” is a perfectly reasonable method name and isn’t I/O you’re inviting eventual disaster by implementing a method with the same signature as oi.Write.

I think a step that isn't directly clear is that you need to be in the nix env for the flake where it should then be available