I think all of my big Nix daydreams are ultimately about (a) making Nix/Nixpkgs use in general more NixOS-like and (b) making Nix/Nixpkgs more widely available. They’re more user- even consumer-focused than they are centered on the health of Nixpkgs. Some of them might not actually be that big.
The main thing is this: NixOS is the first-class way to use Nix, not only because it has control of the whole system, but crucially because the main way to go is declarative by default and it includes capabilities for not just installing but for configuring tons of software. In virtue of such features, NixOS is awesome, in a way that installing Nix and using nix-env on Ubuntu or macOS just plain ain’t.
But the fact is that NixOS will not always be the first, easiest, or even best way that Nix might be used in a given case. So with that in mind, I would direct this fantastical army of engineers to work on:
1. A grand unified module system
Use of Nix configuration modules for operating systems other than NixOS should be a first class experience and the recommended approach.
Concretely, this would look like
- Unifying NixOS, Nix-Darwin, and Home Manager so that instead of modules copying and pasting from each other and coordinating interop at a distance, they live in one repo and share code via something like the Nix process management framework
- adding support for systemd-based foreign Linux distributions, analogous to Nix-Darwin for Linux
- a unified profile manager for working with both user profiles and the system profile (replacing the
nixos-rebuild, darwin-rebuild, and home-manager commands)
- once the pieces are in place, modules can start being ported over to the more universal system one-by-one
It goes without saying that the NixOS-ification of the wider Nix world would benefit immensely from some kind of provenance tracking for values configured via modules, so that we don’t get weird, distant error messages. (If Nickel is the path of least resistance here, great.)
I think this could be a huge help for making really pleasant, stable experiences available to new users. I think it’s also kinda overdue in that the proof of value is already there, in the use and maintenance of the third-party module systems.
2. Native Windows support
This would be a priority for me because without a paid team, it seems unlikely to get the sustained effort required to develop it and push for its integration. The more concrete goals:
- drop Bash in favor of a nice shell that runs on Windows without big compatibility layers, like Nushell or Elvish or Oil
- help flesh out uutils, the permissively licensed, Windows-friendly, Rust clone of GNU coreutils, and bundle it with the shell for the new stdenv
- combine this with the existing and largely paused Windows porting efforts
3. Idiot-proof Nix environment setup
The Nix installer is the place where a lot of people are going to encounter Nix for the first time. The places that set up all the necessary paths and environment variables are the places where that is most likely to break or require cleanup, and also where things will simply seem broken to users of non-POSIX shells. This has been a source of user frustration for years, and getting this piece to be stable is especially important if we want to have NixOS-like experiences on other operating systems.
This means we need something better than nix.sh and nix-daemon.sh. Imo we should either have nix do this itself or we should have a super simple binary to set up the environment. There should be two ways available to Nix users for Nixifying their shell environment:
- have a program emit code in the appropriate shell language for them to have their shell source, or
- have a program prepare a correct environment and then exec into any shell (maybe
makeBinaryWrapper could be extended to produce a program that does this? idk)
with the latter being more important because it sets up the Nix environment as early as possible (obviating hacks like we need to make the Fish shell work reliably on NixOS) and because it can work completely regardless of what shell the user prefers and what its language looks like. I’m not sure if the former is necessary at all, but it might be nice when users have shells that can’t exec and they want to Nixify their running shell. (Emitting shell code would also give users flexibility to (re-)set up Nix later than other badly behaved software that might clobber their PATH or whatever.)
4. An LTS release
I don’t think much needs to be explained here, but that NixOS only has very short-lived releases makes it hard to pitch or use in some places.
Maybe this could be NixOS/Nixpkgs’ own thing, or maybe we could import source tarballs and backported security patches from some upstream distro (rhel2nix? lol). And maybe NixOS/Nixpkgs doesn’t need LTS releases to be as long-lived as they are with some distros, because of how easy NixOS upgrades can be.
Regardless, having a dedicated team sorting out how to get some Nixpkgs/NixOS releases out there where a substantial subset of packages are supported for at least a few years would be a huge deal and seems likely to require this kind of financial and engineering support.
I think with those four things, a lot more users (especially developers on macOS or Linux) could easily jump in with Nix and have a great experience without much commitment or up-front setup.
