That’s why NixOS (and Flakes) is a disaster for beginners! And yes, that’s my opinion and it probably doesn’t interest anyone, but that’s the way it is. I’m not a developer, so of course this is a PEKAC problem.
I’m a big fan of the concept behind Nix, but does it all have to be so tedious?
[nixos@nixos:~/git]$ nix flake init
error: experimental Nix feature 'nix-command' is disabled; add '--extra-experimental-features nix-command' to enable it
[nixos@nixos:~/git]$ nix --extra-experimental-features nix-command flake init
error: experimental Nix feature 'flakes' is disabled; add '--extra-experimental-features flakes' to enable it
[nixos@nixos:~/git]$ nix --extra-experimental-features flakes init
error: 'init' is not a recognised command
Did you mean edit?
Try 'nix --help' for more information.
[nixos@nixos:~/git]$ nix --experimental-features nix-command flakes flake init
error: 'flakes' is not a recognised command
Did you mean flake?
Try 'nix --help' for more information.
[nixos@nixos:~/git]$ nix '--experimental-features nix-command' flakes flake init
error: unrecognised flag '--experimental-features nix-command'
Try 'nix --help' for more information.
[nixos@nixos:~/git]$ nix '--experimental-features nix-command flakes' flake init
error: unrecognised flag '--experimental-features nix-command flakes'
Try 'nix --help' for more information.
[nixos@nixos:~/git]$ nix --experimental-features 'nix-command flakes' flake init
wrote: /home/nixos/git/flake.nix
That’s why. You’re not meant to accidentally use it.
It was less tedious 4 years ago, and when a breaking change happened there was massive uproar that the project didn’t make it obvious enough that things were experimental.
Damned if you do, damned if you don’t.
The push for beginners using flakes right off the bat is honestly the real problem here. You probably should not be using experimental features of anything until you’re familiar enough with the ecosystem to understand what you’re doing.
I do agree that the error message could be improved a bit, and I’m sure patches are welcome.
Frankly though, arguably more than half of what you’re complaining about here is bash syntax, and barely has anything to do with nix.
You’re going to be writing a lot of bash around here. Understanding bash quoting and CLI arg parsing is fundamental knowledge without which you’re going to struggle. You’ll struggle doing anything in the software field without that knowledge.
Using nix as a non-developer takes a lot of interest and willingness to go through learning journeys like this. The people I’ve seen succeed have universally had extensive sysadmin experience or were very determined. There will be many more things to complain about, and they’ll be far more subtle and complex than what looks like 10 minutes of fiddling with quotes.
I really don’t think this is the thing that makes NixOS hard to use as a beginner. Or at least not any harder than Arch/gentoo, or other more adventurous distros.
Yes, but. It should be noted that CLI interfaces do follow certain standards, and the Nix CLI violates them in several key ways, because its parser is handmade and quite idiosyncratic. For example, someone familiar with the Unix ecosystem would expect --experimental-features=nix-command to work. Similarly, separating values by space instead of by comma is a weird choice.
P.S.: One can specify --extra-experimental-features multiple times: --experimental-features nix-command --experimental-features flakes
I do get the sentiment as I had my fair share of struggles with nix and nixos. I recommend reading a guide to setup everything. At least you will get a basic understanding of how things work. I recommend:
Agreed, yes. There are definitely ways the nix CLI could be improved.
I don’t mean to discredit the poor UX experience at all, I’ve definitely stumbled assuming that nix follows gnu semantics as well.
It’s a pretty common experience when using any tooling, though, very few CLI tools actually implement a standard, and even the standards themselves make some odd choices (though certainly fewer than nix). And then many tools use different standards… Figuring out CLI tooling always takes some fiddling with quotes.
I’m just trying to temper expectations. You can’t escape the 40 years of stuff underpinning nix, and a lot of that is confusing. NixOS exposes a lot of it, and adds its own leaky abstractions. If you’re expecting a frictionless experience you’re in for a ride.
I don’t want to be rude here, but have you read the documentation properly? Flakes - NixOS Wiki
It is clearly explained what needs to be enabled prior using nix flake init.
So yes if beginner = I don't wanna waste time reading documentation and want a plug and play solution then nixos isn’t for you.
Learning curve indeed is much harder than most distros for sure but it pays off to maintain, fix and update long term.
However there’s quite a decent documentation for nix and its eco-system and community is very supportive so if any issues or questions, there’ll be someone to help out.
I only had 1 year on Linux with Ubuntu then Fedora then I switched to Nixos without much hassle, actually less hassle than these 2 to maintain, keep the system clean, manage Nvidia drivers, etc
Myeah, that isn’t documentation, but a user maintained wiki, though. Tooling should not be so hard to use that you need to get user notes to actually use it.
There is a real UX problem here. And we’re not even talking about the footgun that is nix-env, this is the polished new 3.0 UX.
nix command being an experimental feature of the nix command is a bit ridiculous. Making the user specify multiple values passed to --experimental-features separated by space is an unfortunate choice that can’t entirely be blamed on bash.
The point is that the nix command itself is experimental. Again, the stable CLI is currently the set of nix-* commands. This is just how people built CLIs back in the 2000s, even if it seems ridiculous from a modern point of view.
Nobody every complains about the apt- family of commands… In fact, most people still seem to use apt-getdespiteapt existing. And hey, apt has been considered experimental for longer than nix, and we have loads of CI tooling using apt despite it being explicitly marked experimental. Looking forward to the global CI blackout when a breaking change is finally made.
Sure; the designer probably intended for you to specify the flag multiple times. That also maps cleaner to the error message. Either way, clearly the UX of the command hasn’t been fully figured out yet. It’s almost like it’s still experimental
Nowhere did I say that having dashes in your commands is ridiculous. I said thay having a feature flag for the whole program is ridiculous. If you don’t want people to use it, just don’t package it by default.
--experimental-features nix-command,flakes would be less bothersome.
Haha, so recognizable. I was up and running with NixOS in 15 minutes, added all the packages I needed to my list and can be productive.
But many things I need are outdated in nixpkgs (the Proton stuff, django, poetry etc) so I try the more fancy stuff, including Flakes. But I often give up.
One day, one day! It just has to click! You know, you’re on the bleeding edge of a new paradigm, maybe one day there will be Ubuntu Declarative Donkey with a central yaml file and we can all be declarative and reproducible and fancy (yeah yeah, I know yaml is not a programming language.)
Only use flakes if you want to simplify complexity (and adds to portability). In fact, what you can do on flakes you can do on normal nix and vice versa.
You will most likely not need flakes if you only manage one computer.
In my case though, I manage 10 systems within the same configuration. Flakes make my life so much easier on this regard because I get to reuse 90% of the code I wrote and it’s plug and play in case I have to reinstall.
Well, as a super noob, Nix would be very easy if it was just “finding the name of a package and adding it to your list”. You can keep the list + some config in Git + you get bootable “snapshots” for free. Already reason enough for me to use NixOS. Plus, stuff like Gnome and KDE are very fresh, which I also like.
But as of now, I don’t even fully understand your remark (and I ahve a PhD in Biophysics).
Right, @fricklerhandwerk basically points out that, no matter how you choose to write your NixOS configuration, it doesn’t change which version of NixOS - and thus which version of various packages - you’re using.
You might be under the impression that flakes are the only way to use multiple NixOS releases in the same configuration, but that’s simply not true; no matter how you configure your system, you can use unstable packages on a stable system - or even packages you wrote yourself that grab the very latest version directly from upstream.
If you’d like some help figuring out how to do this, open a separate thread - but basically, you have some misunderstandings on how NixOS works, and this clearly leads to pain that you really don’t need to experience
Okay, so one of the fundamental misunderstandings here[1] seems to be that grabbing some random Nix expression will fix the problem with outdated software. Sometimes. But generally that‘s not the case, this is why there is a concept of distributions to begin with. Otherwise you could just always get all of the applications from their source repositories. No, you need all of the software to build and run together. And the further apart the system a given piece of software needs to run on from the system it was developed for or tested with, the less likely that’s going to work.
Nixpkgs can be thought of (approximately) as one huge dependency graph that resolves correctly thanks to unfathomable amounts of curation by volunteers and lots of automated testing.
And “simply making a list of applications“ is also falling short of reality. If the only means of composition for software was through command line arguments and pipes, yes, that would be enough. But there are also (shared or otherwise mutable) files and ports and sockets and device drivers using various protocols, all of which need to be wired up just the right way for different applications to work with each other. A “package” is not just a bunch of files, but also metadata that tells us (and the machine) how files with different meanings can be put together.
This is where NixOS comes in, where the unfathomable amount of curation by volunteers is needed to allow applications to work together on that other level. It’s a huge richly typed library for a computer program you can put together, and the output of which is an operating system distribution — essentially an executable that runs on bare metal — that does what’s described by that computer program.
If one thinks about the problem for a while, or if one is in for the long game, pretty quickly it gets more efficient to help curate the distribution instead of cobbling together one’s own ad hoc every time something falls apart that was never meant to fit together.
The fitting together only ever happens naturally in the distribution.
and it’s normal to have them, computers are complicated, that’s the reason we use Nix — to handle that complexity somewhat sanely ↩︎
(and I ahve a PhD in Biophysics).