[all] Re-add nix

[shish]

[all] Re-add nix

It would be good if this could be made fast and simple

Original commit changeset: effc157

---

Stack created with Sapling. Best reviewed with ReviewStack.

• -> [all] Re-add nix #148
• [all] remove nix #147

[will-ca]

It would be good if this could be made fast and simple

Maybe compare the original #77 with the size of #119, or indeed #147?

(Note: The GH diff for #77 is broken/incomplete because you cherry'd and then I synced while we were still working on it, so you'd have to go commit-by-commit or check out the branch to diff it. But IIRC it wasn't really slow, unless you were in a language where you were having to download clang for the first time.)

#77 Added Nix-based dev shells for all the programming languages at that point with only 200 or so new lines of code.

#119 Brought Nix Flakes, packaging, and GH Actions integration, for an additional 1,100 lines.

In #147, removing Nix has touched 1,400 lines, almost equivalent to an entire new implementation language.

I'm sure Flakes have their technical benefits. And a lot of people who are really into Nix are really excited about them. But I'd expressed my general perception in both #77 and #119 that leaning too hard on Nix systems for a project that isn't fundamentally about Nix might lead to spending your effort just setting up and maintaining the Nix components instead of actually using Nix to work on the project.

Based on #147, it sounds like that may have happened. Whatever benefits deeper alignment with "The Nix Way" brought, it apparently wasn't worth the 6X increase in maintenance burden and complexity.

I bet you could just switch back to the simpler Nix shells from #77, maybe with a couple version number bumps, and have something fast and easy to use. Then if there are things from #119 that you miss maybe they can be slowly added back one at a time.

[shish]

Yup, I think you were right all along - I will take another look at the #77 approach <3

[jbboehr]

I'm sure Flakes have their technical benefits. And a lot of people who are really into Nix are really excited about them.

Just to reiterate, most of the complexity of my PR was in building the packages with Nix. You could still use Flakes to provide dev shells, which still has the benefit of the flake.lock - the ability to easily pin and/or update dependency versions - and more easily import modern Nix dependencies (I mean, compare the original zig shell with the flake version, for example).

Considering I spent perhaps a week's worth of work implementing it originally, I do agree that it is difficult to package this project with Nix and perhaps not worth the maintenance burden. Unfortunately, this project using so many different languages really amplifies the maintenance complexity of the Nix build definitions.

[shish]

Yeah, I get the feeling a more manageable and maintainable goal would be for each language to have its own independent nix config which just sets up a dev shell (so skipping the package building and the glueing everything into one mega-project)?