Besides introducing a completely reworked lock file format and a completely reworked output schema?
I think there is room for more…
But as long as its just hunting for more features without breaking anyones workflow, you can as well release them as they are just today…
I am aware that my opinion is controversial, but I am also aware that I am not the only one who thinks like this.
I see where that could lead to problems for larger projects.
But that wouldn’t be something we would’ve to do every few months.
Anyway don’t want to sidetrack too much here.
And this is exactly why I say, break or release.
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.
This thread doesn’t instill confidence that there isn’t a major breaking change on the horizon.
How can we follow the development of this feature? Is there a roadmap on github? Is there some checklist being worked on to get this out into stable?
(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:
Thanks, I’ll just follow this and will hopefully get notified once it’s resolved. Then I can finally use flakes!
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:
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.
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 don’t think you need complicated maintenance for such things…
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…?
I miss using Niv, it was so nice and simple 
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.
This made me think that it could be useful to get some kind of external mediator involved.
Just a thought.
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.
Please see https://github.com/NixOS/rfcs/pull/136 comment everyone. The RFC needs more community feedback.