So obviously lix has just been released. And this afternoon it has joined core repo as an aux package and therefore we should be able to ship it as the default nix version.
lix offers many changes prominently UX and QOL changes.
We should likely hold off on setting lix to the default nix version until after it is out of beta.
Is there a documentation/ roadmap that outlines when lix is considered stable/ out-of-beta?
Let’s keep both Nix and Lix separately. When we work on modules then we can consider setting the default package used for Nix to be Lix (probably with an alias as well).
Not as far as I’m aware.
Yes this is what I had in mind too.
Also we don’t know if lix will add something that nix doesn’t work well with, like a new builtin, so we should still try to write modules towards nix.
Forgot to mention that lix also does regression changes unlike nix, so it will be more reliable to test against too. As well as fixing a number of bugs.
Given available evidence, Lix seems a significantly more stable alternative to Nix. I don’t really see why it shouldn’t be the default in the not-even-beta aux setup?
After having used Lix for a while, I think its clearly the better choice.
Better error messages, some issues just dont appear that do so with Nix, and also more aligned with the goal of aux (to provide an alternative to Nix)
What speaks against using it as default?
I personally am enthusiastic about making lix the default, I think it has shown it’s going to stay around and is more committed to code health, reliability, etc than cppnix. I think that would have been a harder call a year ago, but at this point it’s clear. That said, I’m new here so this is for sure not my decision.
I think we are pretty set on Lix being the implementation that is shipped. Though since this thread was created plans around an Aux package set have changed a bit. We were originally tracking a fork of Nixpkgs, but didn’t have nearly enough people contributing to manage the workload. Instead things shifted more to R&D, primarily involving Foundation and Tidepool. So it will likely be a little while before we are shipping anything.
makes sense. I think starting from scratch with the package set is likely to be better than forking, honestly. continuous integration is the heart of a distro and a fork would have to start out with equivalent infrastructure for it, whereas starting fresh lets you build something that this community actually understands and knows how to maintain.