Is there a stable path for NixOS or is this all still an experiment?

Help
1

I want to run a stable and consistent OS on my laptop with a clean declarative configuration style. I really like the concept of NixOS and it installs well. It configured all the hardware on my X1 Carbon Gen 11 without any extra tweaking and dropped me into a comfortable Gnome Desktop. I’ve spent decades on the CLI so more than happy to configure from the terminal and write files, but I keep running into this ‘flake’ concept. It seems a lot of documentation and even recommended commands expect that I’m using this ability, but it is clearly experimental and I really would like to avoid using capability that is going to shift underneath me and require me to spend a lot of time updating my configuration files to adapt to a developing idea. I want to have a functional operating environment to support other tasks, not make optimizing my OS and workspace a hobby in this point of my life.

What has me really concerned is the situation with being able to search for packages to install from nixpkgs. This seems like basic functionality to me. Getting any of the CLI tools to do this requires the enabling of flakes. Sure I can alias the command to something to turn on the experimental features just to run a search and move on, but as I go deeper is this type of expectation of running experimental features going to be a pattern that I’ll need to deal with regularly?

This makes me somewhat uneasy about continuing down the NixOS path. Is this going to have a relatively stable path I can follow with some intelligent decisions or am I going to have to make maintaining my NixOS configuration a hobby constantly shifting to address various experiments and changes in order to run reasonably updated versions of the software?

Can you convince me to stay? I like what I see and want to, but don’t want NixOS to become that needy friend that I love, but seem to constantly be needing help dealing with their crap and not getting anywhere.

2 Likes
2

The flakes interface may be subject to minor change, but that will mostly be contained to your flake.nix, which in my case it is just a small part of my config:

$ fd '.nix$' -X wc -c | tail -n1
505845 total
$ wc -c flake.nix 
9062 flake.nix

Changes may include minor bikeshedding of attribute names or their order. For example we may see a change from packages.86_64-linux to 86_64-linux.packages. This is however trivial to fix in the flake, and the old interface will likely be supported for a great while concidering how widespread flakes already are. If you use a framework like flake-utils or snowfall lib, then you may not even notice this change at all.
The major boost in UX offered by flakes is very much worth it.

3

You’re touching a somewhat sensitive topic.

First party documentation deliberately avoids this. There are third party docs that focus on it precisely because the first party documentation for it is still scarce, and because it’s frankly useful and has fewer footguns for new users.

Yes, it is experimental. The API has not had deep breaking changes yet, only some command line args have shifted. So far, people have been careful to not break stuff.

This is paradoxical, given it’s marked experimental. There are calls to both finally break stuff and calls to just mark it stable immediately. You’ll probably get people from both sides of the argument telling you to either avoid it or use it, backing with opposing views on the experimental tag.

For the moment, if you really don’t want to experience breakage, it’s probably best to take the experimental marker seriously.

That said, I don’t believe changes will be particularly invasive for a NixOS config. Most of that is nixpkgs, which won’t be affected too badly by changes to flakes. As long as you don’t put everything in your flake.nix, you should not be affected much by potential breaking changes.

nix-env -qaP still exists, no? Sure, it’s slow and has issues, but it’s how we used to do it.

In general, there’s very little you can’t do without flakes. Nix and NixOS have existed and been usable for years before flakes were even thought up.

Flakes only put a variety of different features and use cases under a new, renovated house, to make them more visible and accessible. They don’t really add any completely new features.

I do personally recommend them though. The UX is much improved.

2 Likes
4

@TLATER
I just tried nix-env -qaP again and it does seem to work now. I’m not sure why it wasn’t before. Maybe I just saw someone say that nix-env was being deprecated or something so was avoiding learning it. :slight_smile: Thanks for the re-trigger.

1 Like
5

What is the “major boost” you get from Flakes? Admittedly, I’ve tried to avoid getting nerd sniped by the coolness since it is experimental. Maybe I shouldn’t resist it too much?

6

When doing nixos-rebuild --flake . it automatically tries the current hostname, effectively becoming nixos-rebuild --flake .#"$(hostname)"
This allows me to have the config of several hosts together without resorting to a per-host symlink in /etc/nixos.
I also don’t have to use /etc/nixos anymore, I can put my config wherever.
I don’t even have to have it stored locally: nixos-rebuild --flake github:username/repo. This path can be set as the flake path used during auto upgrades.

I don’t have to worry about the nix channels anymore, i can just use nix run unstable#some-package when i need to.
If i want to try out a package from someone elses repo, like an open PR, then I can nix develop github:username/nixpkgs/branch#some-package.

The flake.lock has saved me on multiple occations, mostly when pandoc is concerned.

You can define multiple shells without repeating yourself too much. In my config i have three different shell, depending on whether .remote.toml is present, and whether it is being entered on a remote using remote-exec

7

This can be done with traditional nix commands too, using the nixos-config component of NIX_PATH.

Less intuitive and somewhat akwkward, sure, but it’s possible.

Generally flakes just have much nicer UX. Channels are indeed gone completely, and with them the issues caused by having multiple and not understanding the implications on updates.

There are some downsides too, like making it more awkward to match up different projects into one version of nixpkgs (for disk space reasons). Some others and general arguments live in this thread.

Personally I think the upsides by far overshadow the issues e.g. with installing through nix-env (nix-env -qaP is quite ok still), and that the risk of potential breakage for NixOS configuration is very minimal.

Either way, the point is, nix is stable and has been for years, flakes are not required, but very nice, especially for newish users.

1 Like
8

Flakes have been marked “experimental” for about 3 years now, and in that time, the file format has changed exactly once, and it was a very minor change (the removal of the edition attribute), and that happened within the first few months of development.

They are still classified as “unstable” mostly to allow time to stabilize the cli apis, but there is basically 0 chance that the on disk file format will change at all before they reach stable. There may be a “flakes 2.0” at some point which does break the format, but that isn’t anything that’s going to happen before stabilization.

The main advantage is a stricter evaluation with absolutely everything used to build the system being locked to exact revisions, as well as disallowing some “impure” facilities, such as reading environmental variables during evaluation, which guarantees that your configuration is about as reproducible as humanly possible.

1 Like
9

Ah! Yeah that sounds like where I got confused about the use of nix-env. Thank you!

10

I believe the replacement of the default attributes with the default package/module etc. also counts.

1 Like
11

Ah, that’s some interesting context. When you say CLI API changes, that means the actual configs in the flakes.nix wouldn’t be changing. The commands used like nix search would be experiencing the change?

12

Pretty much. E.g. nix shell and nix develop still have some open discussions around default shells and some behavior things (e.g. the lack of an alternative for shebangs), nix profile will change to use names instead of indices soonish, etc.

None of those really require changes to what is in flake.nix.

Even if there are changes to some outputs, I’m fairly certain nixosConfigurations won’t see any. Even if I’m wrong, it would be a very easy to fix one-time thing, since the actual NixOS module system would never be affected.

13

I strongly prefer the CLI over web interfaces for most things, but when I started out with Nix and found the CLI package-search experience disappointing (I forget the details, it was a long time ago) I soon found NixOS Search and never looked back.

2 Likes
14

The real problem with nix search isn’t that it doesn’t work well, it’s that many users don’t understand how to use it well. If you simply type nix search nixpkgs foo then Nix will download and unpack the latest revision of nixpkgs based on the registry, then it has to evaluate, all that takes a lot of time. If you type it again later, the same thing happens with an entirely new revision, wasting even more time.

Instead, if you pin a single revision of nixpkgs, say if you are on NixOS, you can pin the system’s nixpkgs to a flake registry entry such as nixos for example, then nix search nixos foo will only evaulate once, and every subsequent search is a lot faster, thanks to the eval cache, at least until you update your system.

1 Like