Determinate Systems Blog

In my last role as a director of engineering at a startup, I found that a project `flake.nix` file (coupled with simply asking people to use https://determinate.systems/posts/determinate-nix-installer/ to install Nix) led to the fastest "new-hire-to-able-to-contribute" time of anything I've seen.

Unfortunately, after a few hires (hand-picked by me), this is what happened:

1) People didn't want to learn Nix, neither did they want to ask me how to make something work with Nix, neither did they tell me they didn't want to learn Nix. In essence, I told them to set the project up with it, which they'd do (and which would be successful, at least initially), but forgot that I also had to sell them on it. In one case, a developer spent all weekend (of HIS time) uninstalling Nix and making things work using the "usual crap" (as I would call it), all because of an issue I could have fixed in probably 5 minutes if he had just reached out to me (which he did not, to my chagrin). The first time I heard them comment their true feelings on it was when I pushed back regarding this because I would have gladly helped... I've mentioned this on various Slacks to get feedback and people have basically said "you either insist on it and say it's the only supported developer-environment-defining framework, or you will lose control over it" /shrug

2) Developers really like to have control over their own machines (but I failed to assume they'd also want this control over the project dependencies,…

Yeah, and that's obviously pretty hostile when the best guide is reading the source.

I think the deeper problem that maybe isn't always considered in the "Nix needs better docs" discourse is that there are many tasks that simply don't have an optimal workflow in Nix (yet). It can be weird documenting how do some particular thing, but having to frontload that doc with a bunch of caveats about which particular set of tradeoffs the suggested approach is embracing.

For example with Python, a huge one is around how much you want to leverage the Python packages already in nixpkgs. If you want to use them, which makes sense if you don't really care about versions or you've got a lot of things with tie-ins to non-Python such as bindings packages, then you probably want the conventional buildPythonPackage workflow, where you manually package any missing deps, perhaps assisted by pip2nix: https://wiki.nixos.org/wiki/Python

But if you have a self-contained app that already has everything locked and you just want minimum friction, then you almost certainly want uv2nix: https://github.com/pyproject-nix

A lot of things in Nix are like this. Same story with containers where you've got dockerTools.buildImage but depending on your workflow nix2container is almost certainly the better choice. Nix's limitations around IFD are finally being addressed by https://tvix.dev/ but that's a rewrite and brings yet another potential split.

Nix is the epitome of being perpetually stuck in the 1000…

A big problem with making an abstraction over CI providers is that they are, on the surface, very little more than wrappers around steps made up of small scripts, but that abstraction leaks like hell. So I think you would wind up needing to go quite high-level to make something that is useful here, but even if you do do this, the variance in runtime environment will make it very difficult to make sure things are relatively portable, and attempts to work around this will lead to problems (e.g. you could just wrap everything in Docker, but fetching large images on each CI invocation isn't really a good use of resources.)

Let's say you have a project using CMake with vcpkg. Vcpkg has support for the GitHub Actions Cache API, so it can integrate very well into GHA and provide good performance for caching dependencies so they do not need to be built on each invocation. Doesn't seem too unreasonable, you could have a vcpkg+CMake plugin of some kind that tries to do the best thing for each CI provider. But, what version of vcpkg do you use? what version of CMake do you use? Vcpkg is essentially just a rolling-release Git repo, there's no specific version to use. But it would save a lot of time to make use of the vcpkg installation that already exists on GitHub Actions images. And obviously, a tool like CMake depends super heavily on the environment around it. A lot of people use the Ninja provider for better performance... but if you use it on Windows, you need to be careful:…

The flakes were the main UX/DX improvement for me. Before them I honestly could not do anything. The learning curve was so incredibly steep it almost felt like the people behind Nix were being malicious or intentionally gatekeeping. You finally stumble onto something you can at least partly understand, but then the powers that be throw two last obstacles at you like,

First, flakes are "experimental", so you have to enable them. Back then there were like three slightly different CLI commands to do it, and it felt like none worked from like 5 tutorial tabs I had open, putting it `experimental-features =` into flake you are trying to switch to does not work obviously.

Then you hit the classic situation where your flake is not committed or staged, so Nix refuses to see it. And instead of telling you that, it prints this abomination of error message "error: path '/nix/store/0ccnxa25whszw7mgbgyzdm4nqc0zwnm8-source/flake.nix' does not exist" (https://determinate.systems/blog/changelog-determinate-nix-331/#untracked-files)

I would not wish learning Nix from zero on my worst enemy, and I say that as someone who uses nix-darwin, devShells, deploy-rs and so on every day. The UX/DX is really bad, but nothing else comes close to its capabilities.

Sorry for rant but without flakes I would not make it.

> Nix has an install step to use a package

Not true. See
"Using Nix to run software with no installation steps" https://determinate.systems/posts/nix-run for example.

This feature has been one of the main use cases of Nix.

> Nix has an install step ... AppFS does not... I'm the author of AppFS.net...

I appreciate the disclosure, as it helps readers (like me) to judge the merits of your claims, especially regarding AppFS vs other options, and whether those claims could be biased (due to differences in familiarity, for example).

> I'm not sure what kind of disclosure is needed...

Over Hacker News and other forums, when the author of a tool wants to promote their work (nothing wrong with this, I learnt a lot with such promotions) in the context of competing tools, the following disclosures are common:

1. Disclosure: I wrote AppFS.

2. Author of AppFS here. (Just like what you did.)

3. Shameless plug. (Note: I personally do not see this as a shame, but I just want to give examples of common disclosure styles in such contexsts.)

My first encounter with Nix was using it that way to get my favorite tools on the university computer lab without convincing the admins to install them for me.

Today, some Steam Deck users are using Nix to supplement their console's desktop experience with familiar tools without the overhead of Flatpak or the risk of modifying the base system (in which case modifications are nuked on SteamOS updates anyhow).

Determinate Systems did some work to enable and document that, and one YouTuber recently posted an intro/walkthrough of their docs as well.

Video: https://m.youtube.com/watch?v=ttOs5iWgNzk

Secondary documentation (YouTuber's blog): https://christitus.com/steamdeck-as-a-desktop/

Primary documentation by Determinate Systems: https://determinate.systems/posts/nix-on-the-steam-deck

(Some of the work relevant here was done by folks outside of Determinate Systems as well. The installer workgroup is not exclusively DSers.)

Sometimes it just fits a use case so much better than alternatives that it's an obvious choice.