It’s nice to see a document describing the stabilization criteria and timeline for a new experimental feature, very nice.
Yes, documents about stabilisation paths are a welcome addition to the development.
But the fact that there are 4+ partially incompatible evaluation engines is something that concerns me.
Same for me… I don’t know where all of this is going. While I appreciate the efforts being made, having many evaluation engines is kinda dangerous.
This change is what will make a .nix file behave differently on Nix where it’s going to fail, and works on Lix. To be honest, I don’t think this is a good idea.
I’m not concerned at all, I think this competition is healthy and only worth it in the long-run. I find Nix development to be rather staggered or even regressive at times and I view Lix as life-support for Nix until we have Snix. I don’t think there’s too much future to the current C++ codebase. I feel like I know exactly how this will go.
By an announcement of the SC, the nixos/nix implementation will remain the reference implementation, and what nixpkgs will have to comply with.
So unless we manage to build up also a snixpkgs or lixpkgs, and an extensive cache for it, I see no future for any of the alternative implementations, only frustration at the consumers end, because they want to use a flake that relies on the lix eval implementation or nix-supers “dynamic” inputs, etc.
Seems like a rather big change to the core of the language and without language spec or versioning mechanisms better than builtins.langVersion I don’t see how the ecosystem could stay cohesive. Appreciate the attention to common pain points, but shouldn’t we eat our vegetables first? In the presence of multiple implementations feature detection and common spec is a necessity.
We should probably all settle on one implementation so that we get the same bugs, otherwise bad things will happen oxide-rs: 0.9.0+20241204.0.0 -> 0.11.1+20250409.0.0 by sarcasticadmin · Pull Request #403094 · NixOS/nixpkgs · GitHub
I literally don’t care, nixpkgs is so much more than Nix evaluator. It may currently be the reference implementation, but that’s only because it’s still the most used. If you know anything about other implementations you would know how important it is to keep compatibility with nixpkgs for cache.nixos.org.
There’s often a dilemma which is whether to redesign something and not rewrite the same broken behavior of Nix thus sometimes getting cache misses, or just keep the brokenness of Nix to avoid hash discrepancies. So far in Snix and I think Lix as well, the former usually gets picked.
That said, we don’t want to create an air of “can’t you just”. It’s probably better that the CI at least match what the users are running. Does finding a bug in Lix, strengthen Nix, and vice versa? If so this is great, but does it? There should probably be a priority on strengthening implementations rather than arguing over purity, or becoming uncomfortable with a diversity of choice.
I agree we should settle, once that implementation comes up on top of the others. I don’t think we should settle for less just because it’s older and more popular.
Does finding a bug in Lix, strengthen Nix, and vice versa? If so this is great, but does it?
Absolutely, notoriously even, if you haven’t been living under a mountain.
Finding bugs in Lix/Snix/Tvix that affect Nix as well and get reported to Nix happens literally all the time.
I wish I could agree with this, but the truth is that I don’t think we should be forced to live with a bad status quo.
(Note: for the purposes of this message, I’ll be using the term CppNix, to refer to the “original” Nix implementation).
I’ve followed CppNix development for a long time. I have a lot of empathy for the people that are still maintaining it - roberth in particular has done a ton of thankless work to keep the ship running. But with every feature introduced to CppNix, I find ten more bugs to contend with. I don’t blame the contributors pouring timeless hours into the project - they’re doing their best with what they have. But I can’t ignore what’s in front of me.
Lix is a relatively “sane” drop-in fork. But the key difference with Lix is that it worked for me when CppNix didn’t. The issues and bugs I encountered on CppNix aren’t found on Lix, because they were never introduced. Did you know that CppNix doesn’t have nested follows support? Or that downloading flake input updates takes 5x as long on CppNix?
The issue that brought me to Lix in the first place was simple - I couldn’t update my flake on CppNix. A bug had been introduced in recent versions which made nix flake update fail. I planned on going back to CppNix 2.18 - a version known for not having recent bugs. But CppNix 2.18 had recently been removed from Nixpkgs, as it was no longer maintained. So my options were:
- Use an unmaintained version of CppNix, which was no longer receiving security updates
- Don’t update my flake until the bug is fixed (meaning I couldn’t download security updates from Nixpkgs)
- Use Lix, an actively-maintained fork that would actually work
You can guess which one I went with.
Even Hydra, the nixpkgs binary cache, faced the same issues as me - it had to use Lix for a short period of time to avoid dealing with CppNix bugs. This decision was hotly criticized, mostly by Detsys employees - but there’s something to be learned here. CppNix wasn’t able to serve Hydra’s needs of being a working Nix implementation, and Lix was.
I agree that creating evaluation differences between CppNix and Lix is going to cause issues - especially when nixpkgs is bound to using CppNix. But my point is - must we be bound to a piece of software that seems to work less and less? One whose contributors seem to keep dwindling?
I understand why the steering committee made their decision, but I disagree with it. It locks nixpkgs into a Nix implementation that only seems to hinder it. I hope in the future, as Lix and Snix develop further, the decision is reconsidered.
There are issues in nix that might justify a hard-fork to push hard to make progress (eg. missing output/binary content sub-resouce integrity hash representing in nix store hash itself) .
The little to no convenience to avoid a type casting of an integer to a string - in exchange for remove readability, security & control is a joke!
I considered over a long time to switch, hoping to find additional build convenience, better usability, detailed visibility and fine-grain control over the build process itself.
The last thing I want from a tool like this is quick spontaneous pointless hard-fork of the language specification itself (and nix environment) without even trying to reach a joined decision.
(Removing lix from personal todo/eval list.)
I need to follow up on this PR but I was able to produce the same behavior I called out in: oxide-rs: 0.9.0+20241204.0.0 -> 0.11.1+20250409.0.0 by sarcasticadmin · Pull Request #403094 · NixOS/nixpkgs · GitHub on nix and lix. It was just intermittent so it wasnt obvious both were effected. Ill update the PR so its clear there too. I dont think the behavior for the PR is related to the issue raised in the thread.
I switched to lix the moment 2.90 was announced simply due to it more than halving the eval times i was frequently seeing with nixpkgs-review. Thanks to this i haven’t really experienced any of the supposed numerous instabilities with recent cppnix since 2.18. What worries me however is that lix is diverging more and more from cppnix, like the forward pipe operator precedence, and now how they plan to enable this integer coercion by default if it becomes popular rather than requiring cppnix to also support it, meaning nixpkgs will have to disable the feature in CI to stay compatible. The lix team is doing some amazing work in identifying smelly code, and in refactoring and rearchitecturing and rewriting parts of lix. But the hostility i’ve seen from some lix devs towards cppnix and the mere idea of flakes on multiple occations worries me and indicates that the implementations will likely diverge more and more.