[development] Provide a shell.nix for development

[NoraCodes]

Is your feature request related to a problem ?

I want to contribute to GoToSocial, and I can write Go, but this would be the only Go project I regularly work on and I don't want to set up my whole system in a different way in order to use it.

Describe the solution you'd like.

I would like the project to provide and maintain a flake.nix and shell.nix, using gomod2nix, so developers who use Nix or NixOS can easily work on the project with nix develop or nix-direnv.

The maintenance of this development setup would require that someone with Nix run gomod2nix whenever a dependency is added or updated, in order to keep the nix environment synced up with the project. This is an infallible step and does not need to stay perfectly in lockstep; any Nix-using developer will be able to do this at any time.

Optionally, the version number written in the Nix config will need to be updated when new releases are cut.

Describe alternatives you've considered.

Simply not doing this is an acceptable alternative.

Another alternative would be to use a non-gomod2nix method of updating the Nix config.

Additional context.

No response

[NoraCodes]

To be clear, I have this config working locally and would contribute my gomod2nix flake and shell.nix.

[daenney]

As I said on Matrix, in general I'm OK with this idea. However, some of the bits of the proposed solution here I'm not very happy with.

The maintenance of this development setup would require that someone with Nix run gomod2nix whenever a dependency is added or updated, in order to keep the nix environment synced up with the project. This is an infallible step and does not need to stay perfectly in lockstep; any Nix-using developer will be able to do this at any time.

If we're going to add Nix development support, it should Just Work reliably. We shouldn't be in a potentially perpetual state of drift between the repository and the Nix view of it. That also means that checking out the repo at a particular commit doesn't necessarily let you work on it from a Nix environment, or build it, without doing extra work.

Though we don't add dependencies very often, we do update them regularly. That also requires updating the gomod2nix.toml. As far as I'm aware, our current tooling in the form of Dependabot doesn't support Nix, and I don't believe Renovate does either.

Optionally, the version number written in the Nix config will need to be updated when new releases are cut.

I would like to avoid extra work when doing releases. It's currently automated fully using goreleaser, so we'd have to fold that in somehow. GoToSocial is also already packaged in nixpkgs. But it sounds like we'd now have to explicitly bake version numbers into source files within the repository, which is not something we currently do (they're injected at build time in the Go binaries).

I'm wondering if there isn't a way of maintaining a gotosocial-nix repository for the community to collaborate around, without this needing to be maintained in the main repository?

[daenney]

A few other things that came up in a follow-up discussion in Matrix. If we want to provide a full Nix-based development environment, then we also need to take into account that:

• The web UI has a JS/TS stack
• The docs have a Python stack (use Conda currently)

The docs stack isn't crucial, since you can preview most of it with any Markdown previewer. But it's definitely handy to be able to preview the docs fully rendered locally.

The web UI should be included otherwise we only have a partially working dev environment.

[daenney]

To summarise the conclusion from Matrix:

• We're happy to accept a PR that makes it easier for folks on Nix to develop on GtS

• We won't accept a PR that requires:

  • Dependency synchronisation (gomod2nix and similar)
  • Keeping track of version numbers in source / doing additional dances at release time

  Neither of these should be necessary for a development environment

A few different suggestions have shows up in the Matrix channels on how that could be done. If anyone wants to take that on and submit a PR, please feel free to.

[daenney]

I'm going to close this for now, as we ourselves don't intend to implement this. If someone wants to, the constraints noted in https://github.com/superseriousbusiness/gotosocial/issues/2638#issuecomment-1952650633 should provide the necessary guidance for how to craft a PR that implements this that we'll be able to merge.