Many people have been migrating to npins, and the new system.nix.
I think it sees less adoption because it doesn’t have a commercial entity marketing for it, because it isn’t inadvisably built-into nix, and because it doesn’t come married to the much better nix3 CLI. There’s also a huge first-mover advantage.
Less footfall ultimately leads to network effects - less documentation, fewer blogs, no youtube videos made by people with far less insight than audience. Hence fewer people know about it, so fewer people use it, which means less footfall, which …
So while it’s a good solution to the single problem most people use flakes for, and it doesn’t come with the issues of pure eval or the system debacle, it’s used less.
Water is wet, and marketing really matters.
Last time nix made a breaking change to a feature that wasn’t explicitly experimental (nix search, IIRC the docs mentioned experimentalness but it was easy to miss), orgs relying on stability raised a massive stink. We got the experimental flags because of this incident. If there was no effective difference, we never would have had the experimental flags.
This may not matter to you, but it does affect companies that actually rely on something. Users of flakes are aware of the experimental status, and - if managed responsibly - reserve engineering capacity for when that threat is eventually realized.
Stability is a promise. Don’t make promises you can’t keep, and definitely don’t try to coerce someone else to make a promise they don’t want to keep.
Right, the wording might come across as insulting, that is not my intent, sorry.
My point is that clearly you do not rely on nix’ stability guarantees. There is no value judgement here, there is nothing inherently good or bad about different ways to depend on the project.
Whether or not you rely on stability guarantees is not part of my argument. You, as a person, are not necessary to decide whether or not there is value in nix’ stability guarantees. Arguments are still valid if they are not ad hominem.
You might not depend on it, because your use cases might not require stability or managing engineering capacity. My personal projects probably could cope with de-experimentalization, too (though I have personally moved to lix and will probably be an early adopter of an alternative plugin once that happens).
That does not mean that there aren’t community members who do need stability guarantees, and I prove my point by referring to the origin of the experimental flags. Unless we’ve decided that that part of the community no longer matters, clearly flakes being experimental does make an effective difference, because it has in the past.
I sometimes use Flakes and answered as such. But I don’t want them to be the default. The only reason I use them is that some people only provide their software through flakes. I don’t want them to be enabled by default, it’ll only force me to use them more, where I’d like to use them less.
I think there’s also the much more direct cause (only for system.nix, not for npins) that there is basically no documentation (and/because it’s very new):
ddg system.nix: Lots of results, but none are relevant to system.nix
nix.dev system.nix or "system.nix" non-relevant results (does not seem to support exact match)
In the nixos-install manpage: mentionned, but not explained
In the nixos-rebuild manpage: mentionned and explained, but only a single paragraph:
/etc/nixos/system.nix
If this file exists, then nixos-rebuild will use it as if the --file option was given. This allows to build a self-contained system configuration, without requiring ‘nixos’ channel.
That’s, funnily enough, a differentsystem.nix - you could consider it the system-manager equivalent of configuration.nix. (s-m is a way to handle /etc config and systemd units outside of NixOS - officially they only support Ubuntu, but I’ve used it on Arch, it really should work fine on any systemd-based distro.)
What is your plan though with Lix who plans to strip out the feature exactly? This is why we need a Nix specification. Flakes can’t be stabilized now as a big fork is dropping the feature outside of the main codebase and into its own plugin. To be clear I use flakes and support the idea behind it but the whole feature is flawed in its implementation entirely and I rather see the Nix team stop being scared and actually break the feature (for the better) marked as experimental!
Quite frankly I’m more afraid of Nix becoming multiple languages (it’s already happening) with Lix!
Also lets be real flakes as a whole seem to be a stalled effort: Flake schemas by edolstra · Pull Request #8892 · NixOS/nix · GitHub
Opened for 3 years and not an inch closer to merging. Also I’m just saying we would not have this problem if @edolstra didn’t decide to yolo-merge it!
Wait until you hear that dix has announced that they will continue to support the current iteration of flakes (dubbed it dix3, too, for your confusion), and they’re paid for that, so we’re already doomed to at least one fork being uncompliant with any changes.
Luckily it’s the least-used fork, for now, and probably the one most able to absorb the resulting maintenance burden.
I think @xokdvium 's comment upthread sketches a productive endeavor to preempting problems like this.
A formal definition of the nix language would anyway be useful, non-fork implementations (tree-sitter, rnix) run into a good number of inconsistencies because there is no formal definition, too.
Quite frankly that should make it easier for the Nix team to break it if so many orgs are so desperate to stay on this experimental feature they can pay Dix to continue maintaining that feature for them!
Q: What are your plans for flakes?
One of our primary goals is compatibility. While flakes are an experimental technology, their use is widespread enough that they’ve become a de-facto part of the Nix ecosystem — and thus we consider them to be part of our compatibility guarantee.
As Lix core team, I came to support xokdvium’s excellent take on this. I don’t have much to add as I share almost all of it, except a couple of thoughts:
Flakes already are diverging in many subtle/minor ways as far as we can tell, obviously, that’s entirely legal given their experimental feature status but the fact there’s not so-much experimental and people are now relying on them as public APIs is causing churn and weakening the reproducibility promises of Nix. If you care about that for your projects, staying away from Flakes is still the best strategy, IMO.
Many Flakes alternative have been attempted in the past without touching to the core of Nix, e.g. dependency managers like niv, npins, lon, etc. and entrypoint organization systems like sprinkles. Unfortunately, the convenience of Flakes is its integration and it being integrated makes it a “default choice” to converge on. The lack of real / true competition on that field is a loss of opportunities for the users, IMO. It cannot come only from the interpreter people because there’s already so much to do.
I don’t think it’s hard to get Flakes out of the experimental state as long as you accept there’s no one Flakes implementation but many of them (this is the reality today). Once the problem is framed that way, stabilizing Flakes becomes extracting Flakes then making it easy for anyone to plug their Flakes plugin, IMO. Even if boundaries of Flakes requires a common understanding of the language, e.g. should flake.nix be a trivial Nix expression? What is trivial?, evolving an out-of-tree plugin is way easier than evolving a monolithic fragile thing like a Nix interpreter.
nix3 CLI (also xp) is also a local optimum and an afterthought on how to design a UX friendly CLI. With unlimited resources, conducting proper user research and analyzing what is sought out of such a CLI would probably lead to a bunch of insights worthwhile to implement.
If people feels themselves limited by Flakes not being stabilized fast enough, I think it’s easy to go see an interpreter person or a project and propose funding to get this over some sort of finish line.
…doesn’t help the argument and is trivially fixed, but still funny to remember that -A in the new nixos-rebuild is broken conditioned on presence of flakes in nix.conf
You don’t have to leave though, you can choose to ignore the SC. SC is simply another team, they work to earn respect of their opinion just as anyone else does
OK but let’s break the flakeref syntax subtly first! (EDIT: meaning, make them valid URLs permitting extension to non-flakes)
Ah, I’m not sure that’s correct, right? They do have a degree of supremacy in decision-making, which they generally shouldn’t need to invoke but which is critical for their role. Or have I misunderstood their remit?
