Flakes are marked as experimental, which usually means “may break every day”. Though there hasn’t been any major breakage since the release of 2.4.
Due to this too much adoption happened, which again made everyone carefull to not break the adopters workflow.
We are in a situation that can only be resolved by either releasing and postponing breakage to a “flake 2.0”, which then will be more aggressivley experimented with, or by just starting experimenting and risk breakage right now.
(I left a comment before reading some of the thread here, and it turns out my point was largely redundant)
I am also fairly annoyed with the way system is handled with flakes. But I’m also annoyed at how people have basically thrown overlays out the window because of the non-composable static outputs attrset. If I have to override a common dependency to add a patch or something, it’s now a rat’s nest of manual .override calls and praying that I didn’t miss anything. That, or I have to fork something and then I’m left with the same problem except with a rat’s nest of follows.
I know the output schema includes an attr for overlays, but it seems like no one ever uses it, and it’s also not clear whether a flake is expected to include its own inputs’ overlays in its output overlays, or if the consumer of the flake is expected to compose them. It’s a mess.
Personally, I think flakes really need solutions to these problems. But it doesn’t seem like that’s ever going to happen, so I guess they should just be released as-is
Note that there is also a bit of controversy around flakes. The feature has been implemented without going through the RFC process, lacking input from community. As a result part of the community rejected flakes.
Many also feel that it is a too big monolithic change to the Nix language, parts of which could just as well be implemented outside of Nix (see e.g. niv for managing and pinning sources) and promoting one true way will stifle innovation. Having less controversial features like nix-command and evaluation caching tied to flakes is also considered unfortunate.
However, there is currently a new RFC to try to resolve this situation:
I’m fine with there being made a final overhaul to remove warts given that it still has the “experimental” label. I think that can be defended and it’s an opportunity not to be thrown aside.
I won’t really mind if I have to rewrite a bunch of flakes.
I’d challenge this perception. Break it if there’s a good reason and a final design on the horizon.
Has the work been done on such a target design? I agree that if it’s going to be: “We’re going to break it but somewhere between now and 18 months from now” then you might as well consider it to be final.
The community needs to get over itself. How long has everything been blocked by this now?
My question:
I’ve been told there’s a competing proposal to flakes but I can’t find anything. Can somebody point me at it?
Or is it to throw out flakes and leave things as they are? That can’t be it, can it?
The community is not what is blocking Flakes. Flakes being not finalized is, as I understand it. And finalization will necessary take time, there are problems to resolve.
There are definitely people promoting Flakes without sufficiently emphasizing or even downplaying their experimental nature. As a result of this recklessness, there will be people using Flakes, who have not performed a proper cost-benefit analysis of the feature. This essentially forces Nix to one of the following options:
freeze Flakes in their current state, unresolved issues that cannot be fixed without a BC break and all – ugly
forever include an alternative code-path to support Flakes in their current state – lot of extra work
break hundreds of repositories, some of which are no longer updated – goes against long-term reproducibility, one of the main selling points of Nix
Where have you heard that?
Another option is waiting for the stabilization patiently. If you want pinning sources, niv is not going anywhere.
I honestly don’t see a big problem here, maybe I’m missing something.
Breaking change happens in software a lot. As long as it’s properly announced this is just normal in IT. And it’s hopefully not going to happen every 6 months.
We’re talking about a feature that is marked experimental, it might happen that some home user doesn’t know the consequences but then the collateral damage won’t be that big (of course a tragedy to them, not to dismiss this). However a company building a product on top of Flakes hopefully has done their homework in this respect and knows what they are doing.
The chance of third party repos working forever is quite optimistic. They would break anyway at some point. It’s not like all of nixpkgs stops working.
Niv is a third party project maintained by a single person.
IMO not really a much better foundation than just using Flakes which is integrated directly in Nix. At least that was my reasoning when I decided agains using Niv.
I didn’t say it is.
However if it doesn’t provide a significant advantage I prefer to use builtin tools.
E.g. if we had a built in way to encrypt files I would stop using agenix as well.
To be clear, this isn’t really the case with Nix itself. Nixpkgs/NixOS, sure, they have breaking changes all the time. But Nix itself very rarely has breaking changes. That’s how we’re able to use new Nix versions to build ancient versions of NixOS.
That said…
This is the actual argument in favor of allowing breaking changes in this respect. Although breaking changes are very unusual for Nix, I think that tradition matters exactly 0% for an experimental feature.
There’s a lot of resentment around the topic that has to be worked through. It’s a bit ridiculous.
If there are significant improvements, now would be the time to break. It seems at this point first the RFC needs to be merged and then still a bunch of work needs to be done on flakes without really that much clarity…?
One thing I’ve wondered a bit about is why one couldn’t have a function builtins.isolate (or something) that takes an expression as argument and evaluates it in the more restrictive way, like in Flake outputs? If the argument to isolate is a function that takes an attribute set then isolate could populate the argument from the available free variables, similar to callPackage. Wouldn’t such an isolated expression be cacheable? And you could feed the isolated expression using Niv or whatever.
This is just some idle thought I’ve had, I imagine there are multiple problems with this that I haven’t thought of.
There’s a lot of resentment around the topic that has to be worked through. It’s a bit ridiculous.
Even though I’m part of the “uses flakes everywhere”-side I gotta say that there are good reasons for this (the way how this technology was adopted, the way how the RFC process happened etc.).
Also, as said by others there are a bunch of important issues to tackle first (mostly lazy trees), but that has been discussed here already in great detail already.
What I want to say is: issues and concerns have to be resolved. It’s absolutely OK to not know about all the details (a lot of that happened/started a few years ago), but especially then calling this ridiculous doesn’t help at all and isn’t very nice either IMHO.
It’s not my goal to be nice. I’m a relative outsider who has no cultural or technical investment in this. I think it’s productive to offer some perspective especially when things here have been stuck for years now.
I think you have a cool thing here and things need to move forward. That’s all.
That would be a huge hassle and should only be done as a last resort.
I’d start with getting the people in the same room. Have them talk it out and decide on a course forward and if they can’t decide, escalate it to the next best authority.
I don’t think I’m qualified to rework any part of the RFC but it feels complicated and I’m not confident that even when it’s approved that the plan that it sketches out will be executed with any urgency.
