Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[development] Provide a shell.nix for development #2638

Open
NoraCodes opened this issue Feb 14, 2024 · 4 comments
Open

[development] Provide a shell.nix for development #2638

NoraCodes opened this issue Feb 14, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@NoraCodes
Copy link
Contributor

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 NoraCodes added the enhancement New feature or request label Feb 14, 2024
@NoraCodes
Copy link
Contributor Author

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

@daenney
Copy link
Member

daenney commented Feb 14, 2024

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
Copy link
Member

daenney commented Feb 14, 2024

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
Copy link
Member

daenney commented Feb 19, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants