People already treat them as stable because they are the best we have and they have been around a long time
But people also dont fully rally around them because they are not stable.
If they were made stable we might even see more changes being made to them than when they were unstable, despite them being unstable for so long specifically to allow them to be changed.
I am hopeful that the new changes of installing an actual board will fix this. I just hope the people chosen make actual decisions.
Direction is good. Do we want them, or not. Decide. If not, we NEED a replacement, because what we had before was not good enough.
In my book, flakes are good enough. Could they be better? Yeah, but most of the things Ive heard being proposed to make them better have been either, A, non-breaking stuff about inputs, B, trying to say we should have a module system like flake parts be built in as part of flakes, which I strongly disagree with, as I feel like it increases the barrier of entry by too significant of a degree. Flakes should be simple, a wrapper for your modules or packages that imports stuff and has an accepted output format. If you need extra complexity in them, go for it, but they are at a good mix between functionality and simplicity as is by default.
So, unless we wanna implement the flake-partsy versions of flakes as the new redisigned flake version and make everyone convert, we should make it stable, as all commonly proposed improvements that arent basically flake-parts-by-default that I have heard of are non-breaking.
Yes that’s what I meant too. And for this reason I also agree that we should either make them stable (with maybe breaking changes before) or find something else. The status quo is indeed harmful now.
There has always been … limitations to the ability to make decisions.
However.
We do have a decision process now, RFC process, it just does not always converge.
Flakes were put through it and withdrawn, because people pushing Flakes did not want to immediately fix the numerouts issues brought up in the feedback.
Then later a plan to stabilise new UI, eventually making decisions on changes (or not) to Flakes, fixing the broken layering in the logic, and providing access to separate concerns, has been accepted as an RFC.
The current old-stable CLI is more logically consistent once you learn it (so: better) than the new one, and Nix team is actively fixing that from the new CLI side.
So if we consider quality, and the existing decision processes, stabilising Flakes as of now is making things worse on both counts.
The interest to fix the Flake brokenness is so that there is no atttempt to use them in Nixpkgs before the consistency is achieved.
I hope while you dig into ideological battles that you don’t forget all the people already using Flakes to a sizable amount so they don’t find themselves in front of a huge back porting task or have their config become invalid all of a sudden. When I hear “yes, most people use it and like it, BUT IT’S STILL WRONG!!!” I get scared that these are the people in control.
I also don’t want to be forced to use “Determinate Nix, only $12.99 per user and month, don’t lose all the work you put into Flakes”.
No one is suggesting that using Flakes is ‘wrong’. The issue is that, despite their prevalence, they’re still officially an experimental feature and have been for years.
Before flakes consuming any out of tree project was an absolute nightmare! Everyone implemented the interface how to load their code differently and injecting your pkgs into it was different for almost every project, sometimes being hardcoded to load certain channels. None of the other projects like niv or npins can fix that because they cannot enforce an interface.
IMO it would be very stupid to remove flakes at this point.
Incorrect. There is no --pure flag for nix build and friends or nix-build and (most) friends.
What you may be thinking of is either
--pure for nix-shell which only clears some envvars, and is only for development purposes obviously since nix-build doesn’t have this flag
the pure-eval setting which only disables the currentSystem and currentTime builtins, and restricts network access (the latter of which the build env already does anyway…) - note that it still provides getEnv builtin and therefore presumably allows using channels (I didn’t test this, but <> syntax reads from NIX_PATH so this is not really good enough IMO.)
If pure eval already existed I would’ve used it and never complained about flakes.
Unfortunately all the good features of nix are being bundled with the worst possible implementation of a lockfile spec.
You wrote a whole essay about how I should not worry that they are unstable… when my points had nothing to do with that
Flakes are slow and broken by design, I already laid out exactly the issues with them earlier in the reply that I linked.
I don’t care if they are “experimental” or not, I care that they suck. I want the nix team to break flakes and make them better.
Unfortunately Eelco and detsys are the ones who actively blocked any improvements and said “no we want flakes to be stable yesterday” and so we continue to see no progress.
I don’t know why Eelco is blocking it either, and he doesn’t tend to respond on discourse so I doubt we’ll get much answers from him. And detsys is the company he owns, so same deal.
It has nothing to do with effort, though, he explicitly said (if you check the meeting minutes I posted above) that he does not want any breaking changes, while other team members took a more nuanced approach. So I am of the opinion based on cases like these that the nix team overall is more reasonable and Eelco is the one somehow blocking improvements. Of course the team themselves is welcome to correct me, as I wasn’t present for said meetings.
I’m only speaking of things that actually exist, as I find that more productive than discussing things that may exist 6 years in the future with some undefined scope.
But sure, we can look in 2030 to see if flakes are better at that time.
In the meantime, I am speaking about the status quo.
Given the development precedent, not with the current approach to development.
Well, Flake-pushers Eelco included say exactly this to us about a ton of features that work in the current-old-stable interface. And I mean features they wanted to make impossible to implement on top of the abstractions provided by the new interface.
It ‘fixes’ an issue seemingly caused by Eelco’s conflict of interest with DetSys/FlakeHub, it doesn’t fix the fact that breaking changes can’t be made to an experimental feature purely because it could affect one persons financial interests.
Everyone handles the nixpkgs input somewhat differently. I still read the code of every single flake I’m importing (just as I read the Nix code in default.nix before) to make sure I don’t end up with yet another nixpkgs being instantiated making my eval even slower and never receiving updates.
but it is soooo nice and simple to use! at least for any small scale project
And then it ingests all the multiple gigs of a monorepo you’re trying to use it with on every flake-related command. It’s been more than 2 years since the lazy-trees branch (Lazy trees by edolstra · Pull Request #6530 · NixOS/nix · GitHub) was opened and even longer since the issue was first brought up (Copy local flakes to the store lazily · Issue #3121 · NixOS/nix · GitHub) and yet it’s not done, while the people responsible for that PR push for flake stabilisation, instead of finishing this goddamn PR — yes, I know it’s probably not trivial, but then why not try to invest more resources into that instead of DetSys marketing? I wonder how they plan to market it to srs enterprise bznses, if flakes suck for the kind of repos such companies are likely to have? I use flakes and think they are serviceable enough for things like my NixOS configuration and whatnot, but each time I try to use it to support devens at my current $WORK it sucks. I don’t think it makes sense to stabilise something like that, without ironing those issues out first.
Before flakes you would specify the file path instead of attrpath. Both require looking at the code or otherwise running commands to inspect it.
And as a good counterexample to consistency of flakes, the schema recognises HM configs but not HM modules (prior to nix 2.24) so we have proliferation of various HM module structures.
