sorry if this is off-topic, but someone posted this in the nix governance zulip and it expresses what for me is a core concern / hope for aux:
edef 12:20 AM
Another way to think about this is: what would a winning fork look like? What would it take for something to take the wind out of the existing project? I think it probably looks closer to a committed and fairly unitary group going in a well-defined technical direction than a loose confederation of people who can’t agree whether to steer the boat around the iceberg left or right, and hit it by “implicit” consensus.
If flakes by default helps us get there, even though I think flakes are technically sus, I would support it
6 Likes
While I’m happy with flakes I’m not skilled in nix by any means and I even recognize some of those concerns. Although I think they’re mostly fixable (even if they require “flakes 2”).
Also, as an interesting side note regarding versioning and language: Guix has the language itself as a dep (or something similar?) so they can iterate on the language implementation without having to break everything. That’s a nice feature to have.
3 Likes
This is one of the things I’m thinking through right now. When I wrote the roadmap and goals, I also felt this to some extent. That is why it calls out v0 of flakes to get us out of limbo as well as the breaking apart of nixpkgs. Right now I am trying to figure out what the most beneficial thing is for the project, all of the community included.
2 Likes
To be clear: I would still prefer to rip out flakes rather than integrate them as v0. I think we could simply adopt niv or pins like sanix does.
Doing so would break a significant number of projects. I don’t think they can be safely removed at this point. To me it is very much like the experience with the Shadow DOM API on the web. The answer to the problem there was establishing the current, flawed but widely depended-upon, version as v0. This allowed for a stable base to build a better version on top without breaking large parts of the web.
3 Likes
Please permit me to ask you something that comes without any expectation of commitment: how can we reconcile the v0 experimental API and the “classic” or “stable” Nix API? Are we going to rip out channels? Just move forward with the disjunction indefinitely? What’s the solve here?
3 Likes
No, the only plan right now is that the current flakes and cli functionality are non-experimental as a v0. Channels and the previous commands still exist. Functionally all this does is remove some of the frustration with trying to use Nix today.
Moving forward a better, holistic solution can be pursued.
8 Likes
The purpose of the things I called out in the roadmap is to put us in a place where we have a solid foundation to build better solutions on top of. We can’t do that with the current state of “experimental” features which we can’t change. And we can’t pretend that flakes can replace previous solutions right now. Smoothing out the rough foundation right now is what will let us move forward with a single vision for a better Nix story. Whether that is flakes, an evolved version of flakes, modified versions of channels, or something else entirely I cannot say.
5 Likes
I think it could be in our interest to have “old” nix and flakes v0 nix remain under the nix executable names. Don’t change those names to be Aux-centric.
And we can work on the Aux cli experience that is self-consistent and improved under the “aux” executable name.
6 Likes