feat: Nix integration

[valyntyler]

No description provided.

[Necrom4]

Hi @valyntyler, thanks for the PR!

Could you add a PR description explaining your feature? Please also read CONTRIBUTING.md.
Also I cannot accept your PR as of yet because you hardcoded a version number and SHA in the code, that's not how I'd like to release SBB-TUI. Instead I'm using GoReleaser which already takes care of automatically releasing a new version to go and homebrew with each new commit, your Nix feature should also work like that.
Take a look here https://goreleaser.com/customization/publish/nix/ and revert your current commits please.

[valyntyler]

I'm explicitly not packaging this for NUR. I don't see how goreleaser is useful here

[Necrom4]

@valyntyler to be honest I never used Nix and have no idea how packages work in that world, and I'd love if you could explain to me what your goal is. But for sure I don't like the idea of seeing a hardcoded version and SHA in the code.

With your current implementation, where is the package available from? And can't one constantly release a new version to that registry instead of having to update the version manually with each version bump?

[valyntyler]

You won't have to update anything manually. The version attribute is for internal use and doesn't affect the functionality of the flake. You could source it from an external file if you wanted, but for now, I've removed it. The vendorHash doesn't change unless you update your dependencies.

[Necrom4]

Alright, I have multiple question then, if you don't mind

• Does this code you just added ever change? If so, when and how can I update it.
  • You said the hash will change if I update my dependencies, which for now occurs quite often. What should I do in that situation to update it aswell?
• Do flake.nix and flake.lock have to be root? What's the convention?
• Why did you add direnv? Do we absolutely need it and a .envrc? As for as I can tell those will only "activate" if someone has direnv installed, meaning it shouldn't be in the PR and should instead be only local to each developer. Or is this for another use? I don't really know what it's doing here. Also mise effectively already does what direnv does, we don't need two tools then.
• If someone wants to install this via Nix, how do they then update it or select the version they want? Again, Nix is incredibly abstract to me.

I'm asking rather than researching because you clearly know more and this would help me and other people maintain your part of the code in the future.

[valyntyler]

Alright, I have multiple question then, if you don't mind

* Does this code you just added ever change? If so, when and how can I update it.
  
  * You said the hash will change if I update my dependencies, which for now occurs quite often. What should I do in that situation to update it aswell?

* Do `flake.nix` and `flake.lock` have to be root? What's the convention?

* Why did you add direnv? Do we absolutely need it and a `.envrc`? As for as I can tell those will only "activate" if someone has direnv installed, meaning it shouldn't be in the PR and should instead be only local to each developer. Or is this for another use? I don't really know what it's doing here. Also `mise` effectively already does what direnv does, we don't need two tools then.

* If someone wants to install this via Nix, how do they then update it or select the version they want? Again, Nix is incredibly abstract to me.

I'm asking rather than researching because you clearly know more and this would help me and other people maintain your part of the code in the future.

Alright.

1. The nix flake generally doesn't change unless you're doing some massive refactoring that would need special consideration.
2. flake.nix and flake.lock are generally in root. I've never seen a project have them anywhere else.
3. direnv is a nice tool that lets nix people have a nicer time maintaining this. I don't know what mise is, nor am I honestly interested. The flake.nix provides a dev shell without which I cannot develop for this project. Having a .envrc that automatically activates that devshell should not be that big of a hassle.
4. The beautiful thing about nix is that the code is the version. Installing this project through my flake will pin the binary to the hash of a specific commit in your project and changing that hash effectively tells nix to upgrade (or downgrade) your binary.

Hope this helps.

P.S.
I don't mean to be condescending about your current approach for setting up the dev environment. It's just I don't know what this tool is, I don't feel like learning it, and I always set up a nix devshell for anything I contribute to.

[valyntyler]

The flake.nix currently exposes two things, or "outputs". One is the package, which (would) allow anyone to run this from anywhere, with nix run github:necrom4/sbb-tui. The other is the aforementioned dev shell. Nix is a very nice tool for setting up development environments. The way my setup works right now, I need to set up a devshell otherwise I don't have go in my path. I imagine other nix users would appreciate this if they were to contribute to this project. Direnv is a separate technology based on nix, used widely, but not exclusively, by nix users. It lets you source certain things about your environment for convenience. The most common thing I use it for is to automatically "enter" the development shell of a project when I cd into it. That way I don't have to thing about whether I have the right dependencies or package versions for what I'm doing. Another nice feature is that by specifying layout go, it will (as far as I remember) automatically and temporarily put the binaries you build with go into your PATH.

[valyntyler]

Alright, I have multiple question then, if you don't mind

* Does this code you just added ever change? If so, when and how can I update it.
  
  * You said the hash will change if I update my dependencies, which for now occurs quite often. What should I do in that situation to update it aswell?

* Do `flake.nix` and `flake.lock` have to be root? What's the convention?

* Why did you add direnv? Do we absolutely need it and a `.envrc`? As for as I can tell those will only "activate" if someone has direnv installed, meaning it shouldn't be in the PR and should instead be only local to each developer. Or is this for another use? I don't really know what it's doing here. Also `mise` effectively already does what direnv does, we don't need two tools then.

* If someone wants to install this via Nix, how do they then update it or select the version they want? Again, Nix is incredibly abstract to me.

I'm asking rather than researching because you clearly know more and this would help me and other people maintain your part of the code in the future.

1:
One nice thing about nix is that it's atomic. If one thing fails, everything fails. If you make a change that changes the expected vendorHash, nix will fail gracefully, and inform you of what the hash it expected was, and what the actual hash it got was. Practically, this means that if you're bumping your dependencies' versions, building the project once with nix and updating the string should be enough to make it work again. I don't know of an automated way to do this that isn't extremely hacky, though I am not an expert on nix-go packaging

[Necrom4]

Hey, thanks allot for the long explanations, I really appreciate it even though I'm still having trouble understanding everything. I ended up asking AI to complete your answers but I think I finally got there.

So you want:

• To add an installation method for Nix
• According to you, unlike the homebrew/go releases, here the code IS the version, meaning there's no need to manage releases but then what should I do when the vendorHash changes? I don't use Nix and can't rely on you to constantly update it. I need something clean and reliable
• Also as I though mise should be able to replace direnv and even do much more, but as you said direnv seems to be a standard with Nix, so it would indeed make sense to keep it there, although it feels like two tools conflicting. Also people that develop this tool will have to install mise as CONTRIBUTING.md requests it, so if the dev env was set up there, they'd get it automatically on enter anway.

Also:

I don't mean to be condescending about your current approach for setting up the dev environment. It's just I don't know what this tool is, I don't feel like learning it, and I always set up a nix devshell for anything I contribute to.

I understand that but you push a PR without explanation, without following CONTRIBUTING.md and without wanting to use the tool explicitly requested for devs contributors working on this project. When I open the PR and see this, I think it's someone wanting to add a new method of installation, but then I see direnv mentioned, which would go against mise and get confused.

---

So correct me if I'm wrong, but from what I understand:

• we should look into GoReleaser with Nix and see if it'd be possible to update the vendorHash automatically with it.
• If not possible, that means I'll just have to hope for Nix users to update the vendorHash frequently enough (?).
• Lastly, if this is a PR whose feature is a new Nix installation method for the tool, we shouldn't have dev configuration in the same PR. If we want to add it, we can make another commit specificly explaining that and also choose then on between direnv and mise.

During my discussion with AI it also mentioned a few fixes that should be added to your commits, I'd love it if you could take a look, the full conversation is not as long as it seems. And if it is, then the last section:

## Summary / Recommendations

The flake.nix package output is genuinely useful -- it lets any Nix user install sbb-tui with one command, with no publishing step needed. The code is structurally correct but missing some polish (meta, pname/version).
The dev shell + direnv parts are more contentious. They duplicate mise's role and add tools the contributor personally uses. The .envrc should arguably not be committed in a repo that already has an established dev environment strategy.
If I were advising on this PR, I'd suggest:
1. Accept the flake.nix and flake.lock (with improvements: add pname/version/meta)
2. Reject the .envrc -- let Nix developers create their own locally or add it to .gitignore as a template
3. Add a CI step (GitHub Action) that runs nix build to catch vendorHash drift
4. Document the vendorHash update process in CONTRIBUTING.md so non-Nix maintainers know the drill
5. Consider GoReleaser's Nix publisher as the owner originally suggested -- it can auto-generate the Nix package with correct hashes on each release, eliminating the manual maintenance entirely

Bildschirmaufnahme.2026-04-01.um.00.35.05.mov