I see them mentioned in many places and it seems like there’s a shift towards it, but as nix newbie the experimental status really dampens the willingness to invest time for the fear of it possibly being radically changed or at worst dropped.
Is there a timeline or roadmap to stable that can be followed? An areweflakesyet.org? Something?
The feature, along with content addressed derivations (for IPFS and similar things?), looks quite useful and it’s a pity that it seems to be in limbo since… 2018?
Edit: DISCLAIMER: This is my personal opinion/view of things, and I should note that the only actual authority on this are the Nix maintainers. Also, judging from the other replies, it seems like breaking changes are completely still possible, and even desired.
Flakes have already spawned an extensive ecosystem, and indeed, I think pretty much everyone wants them to be stable at this point. There are probably some not-so-small features that are not yet done, which might be one of the reasons they aren’t officially released yet.
However, at this point it’s rather a question of when, not of whether, flakes will be stabilized. Feel free to use and embrace them, don’t worry about them being (too) radically changed or even dropped at this point, I think that ship has already sailed, and their design is pretty much done.
CA-derivations are still much more experimental/in a much earlier stage of development. No idea what the exact status there is, but unless you could really use them for something/just want to try them out, don’t worry too much about them. They will also be released at some point in time, but as an individual user you’ll probably profit much much more from using flakes than from using CA-derivations.
Tl;Dr: You can confidently use flakes, their stabilization is rather a question of when, not of whether.
Personally I have a complicated relationship with the finalisation…
Flakes as they are right now have their problems, some of them are obvious, some are not.
My current biggest concerns are how the system is dealt with in flakes, and how hard it is with the current interface to make cross compilation work, without either violating the flake output schema or using legacyPackages.
They way how nixosSystems is treated specially by nix flake show/nix flake check but darwinSystems/homeConfigurations or whatever else spits out warnings.
The error reporting when nix can’t find files and reports “random” store paths, rather than refering to the “flake and location within”. There is ongoing work on this.
The way how inputs only used internally can explode consumers lockfiles (recursively). Which is also semi actively worked on.
On the other hand side, a lot of necessary changes can’t be done, as flake became a quasi standard with too much adoption. We are in a situation where breaking changes are a necessity, but impossible, as consumers treat flakes production ready…
So I am continuing to ask to either break or release within 2023. There is no inbetween.
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.
