OK, is anyone presenting either (1) PRs to fix flakes or (2) a working alternative to flakes covering all use-cases?
2 Likes
Yeah, has anyone in the community actually approached this from a technical point of view to fix it? I see a lot of discussion but no real action.
6 Likes
-
Lazy trees by edolstra · Pull Request #6530 · NixOS/nix · GitHub (2.5 years old) is meant to address one of the flakes issues (not copying unused flakes to the store needlessly, which should improve performance), and there is no PR (that I know of) to address the problems I listed above. I believe Eelco tried to provide “dev-only inputs” with subflakes, but those are even more broken and I haven’t seen news on that getting improved. For my own personal use I created a patch for a setting to reject all flake config so that my machine is not getting essentially controlled by some remote machine, so that solved one of my own issues. Unfortunately such a PR would never get accepted by nix upstream, same goes for many of the other ergonomic issues, Eelco would simply block those as he has done in the past.
-
Depends on the use case that you care about. I care about pure eval and there is currently no PR to allow for that without flakes. Same goes for a consistent schema (though I’d argue even flakes doesn’t enforce the schema unless you manually run
nix flake check). If you only care about a way to get remote code and store a corresponding lockfile rather than manually specifying fetchers or relying on channels, we have npins, nvfetcher, etc. already.
2 Likes
I loved the promise of being able to declaratively define a fleet of heterogeneous systems and development environments in a reproducible fashion.
What I got instead is a community that is stuck in infantile in-fighting, finger-pointing, snarky and passive-aggressive communication, and endless threads on various platforms about the direction of the project.
Frankly, as an end-user, I am getting seriously tired and frustrated with how the Nix project is handled and how many of the community members behave.
I’ve tried to adopt Nix for a year now. It’s been a bumpy road, to say the least.
Just a few examples I can think of:
I’ve tried to contribute to NixOS Mobile, which resides under the official NixOS umbrella as an exercise to learn Nix.
I bought a device because it was explicitly listed as supported on the official wiki, just to find out that support for the specific device was utterly broken.
The documentation on the wiki is plainly wrong and misleading. Maintainers were not helpful and seemed stressed and overwhelmed by their own project. Getting useful help was next to impossible.
From my brief experience, the problems of the mobile NixOS project seem to be representative of the whole Nix ecosystem: overwhelmed and frustrated maintainers, bad, unreliable documentation, and code that desperately needs a rewrite so that it becomes more maintainable and easier to contribute to.
Concerning flakes: As someone new to NixOS, it’s exceptionally difficult to find good official information on the advantages and disadvantages of flakes.
From the NixOS wiki:
Nix flakes provide a standard way to write Nix expressions (and therefore packages) whose dependencies are version-pinned in a lock file, improving reproducibility of Nix installations. [Emphasis mine]
This is what we get. No section that explains the disadvantages.
How am I supposed to know that Nix flakes might be a bad idea in some situations?
Oh, hold on. This is not from the official wiki. It’s just a wiki that has the NixOS name, turns up first in search results and bears the Nix logo.
Ok. Maybe the official wiki has some deeper explanation that helps someone new to Nix decide:
“Nix flakes enforce a uniform structure for Nix projects, pin versions of their dependencies in a lock file, and make it more convenient to write reproducible Nix expressions.”
Sounds great! Count me in!
Why would I not want to use flakes? The official wiki doesn’t give me any reason not to. No mention of possible disadvantages or pitfalls.
This points to a deeper problem with the Nix project. Documentation, sorry people, is abysmal at best.
This creates needless frustration and friction.
More often than not, I had to dig deep into GitHub tickets and waste countless hours to find a trivial solution for an issue that is very much known to everyone involved but hasn’t been properly documented.
At the same time, I see thousands of characters written by core maintainers of various factions “airing their grievances” about some off-hand comment someone else made in a ticket 5 years ago and how it made them feel bad or unseen, and how this or that person should be banned, unbanned or perma-banned. On and on it goes.
Imagine, all this time and energy was just spent on improving the documentation and creating a shared vision and direction for the project.
While people were arguing in yet another endless thread in this forum, it took a contributor weeks to get the cursor.sh package merged because no one had the time to review their package in a timely fashion.
It’s so utterly frustrating to witness.
14 Likes
At some point, people should look at the values meant to encourage cooperation, and at their own and others’ behavior, and ask: is burning it all down over petty differences really worth it?
7 Likes
You are welcome to improve the status quo.
4 Likes
I think this cuts to the heart of it, though: people’s time and energy is limited, and everyone has the prerogative to avoid a community that is corrosive, or at least looks it from the outside.
2 Likes
As an end-user who recently got into NixOS within the last year, hearing this is pretty scary. There isn’t much documentation on the “correct” way of using Nix channels compared to flakes (in fact, neither has good official documentation). I don’t mind changing my multisystem NixOS config (that’s mainly what I use flakes for) to account for breaking changes; however, completely abandoning flakes and handing everything over to some no-name, for-profit company solely to maintain compatibility—without any alternative solution—is pretty insane, to say the least.
Like I said, I do not mind adjusting my setup to align with what is officially recommended by the Nix team. I want to see flakes either improved upon or replaced with something better! But we can’t just throw out the baby with the bathwater without considering the consequences of such a drastic action.
7 Likes
This is one of the most liked posts in this thread. Take note people, this is the actual crux of the issue.
The way I see it, you are presenting a false dichotomy. We don’t have to choose between making Flakes stable, completely removing Flakes and not doing anything (keeping the current status quo).
The reason, why some part of the community doesn’t want to stabilize Flakes (as they currently are) is because some of the core problems with flakes REQUIRE backwards incompatible changes in order to fix them. And DetSys (and Eelco) are the ones who are blocking these fixes.
Personally, I am currently using flakes, because they are “tied at the hip” to a bunch of unrelated features which ARE quite good. And I do think that we should ACTUALLY start treating Flakes as if they were experimental - break up “Flakes” into a bunch of separate parts (cli, pure eval, a module inclusion/composition system, an output schema, an input/dependency system, a version/revision pinning system for those inputs/dependencies) and then do a proper RFC for each part. And we shouldn’t be afraid to break backwards compatibility, because Flakes ARE still experimental. If we need to call it “Flakes v2” or whatever in order to break this compatibility - so be it.
But let’s not pretend that the only options are 1) nothing happens, keep the status quo forever 2) stabilize flakes as they are right now and 3) throw away flakes completely and go back to “path-based” nix. There is a fourth option - stop blocking and allow backwards incompatible changes and “make flakes great again” (the slogan is a bit tongue-in-cheek, but I think you get the point).
29 Likes
As someone who mostly likes flakes, uses flakes, recommends their use to others, and thinks they should be stable, I just hit something the other day where they weren’t: Nix 2.15 can’t read flake.lock files created by some newer versions of Nix (2.23 at most, maybe earlier versions as well). (I have not yet filed a bug report.)
I understand committing to flakes and pledging to support them, but I don’t think that obviates the need for the existing/ongoing process of stabilizing the interfaces.
1 Like
There is not shortcut to success here, no single quick fix.
Some relevant references.
Progress is slower than we would all like, but progress is being made. We’re somewhere around step 2 of RFC 136. The store library has been split out. Store-only CLI is possible, and commands have been added refined. Build system is refactored. The best thing at this point is help with the steps as laid out.
Jumping directly to flakes - the exciting stuff - is tempting, but help is needed with the un-exciting stuff as well. The key is incremental progress in small steps.
Edit: Additional item, a small step to fix some of the flake annoyances is a half-step toward lazy trees; lazy paths (Lazy paths by roberth · Pull Request #11367 · NixOS/nix · GitHub). I have wanted to help this get merged, but I apologize, I have not been able to do so in a timely manner.
27 Likes
As long as a solution is being actively worked on then I think a lot of the problems here are less warranted. Ideally, Flakes would’ve already been stabilized imo. But it seems like it’ll still be some time.
6 Likes
I didn’t see a single design issue in Flake under this thread. The infamous copy everything problem is actual an implementation trade off in nix cli. If you don’t need pure evaluation, you can use flake-compat and it would not copy everything.
In my opinion it would be a good idea to not dwell too much on design issues with flakes, since it’s neither here nor there without anything concrete to actually do about them, but I think flakes do have some pain points. It’s a hard one to solve but I’d like real version constraints and resolution, rather than just having to bruteforce override transitive dependencies to deduplicate them manually.
And of course, I’ll patiently wait the proper “stabilization” of flakes. I still think the flags are a bit pointless, since many of us have long given up on waiting and just treat it as pretty-much-stable anyways. After all, a stability promise is nice, but it’s only a promise, it’s not worth that much. And, when so much of the ecosystem is on flakes as it is, I don’t really feel afraid to rely on it… things could break, but it’s not like they’ve broken a ton in the past couple years. At this point I’m just hoping for the best.
2 Likes
How about those:
- subflakes don’t really work (More intelligent subflake locking. · Issue #6352 · NixOS/nix · GitHub),
- you can’t modify how the self input is built (Support self-fetching parameters in flake.nix · Issue #5312 · NixOS/nix · GitHub),
- flakes can’t accept parameters (Support self-fetching parameters in flake.nix · Issue #5312 · NixOS/nix · GitHub).
The last one probably can be workarounded with modules (but you force downstream users to use them), but the first two don’t really have a good solution IIRC. I’ve personally was more than once annoyed by flakes not being modular.
6 Likes
I’d like to invite you to try https://devenv.sh, it has a much better DX than flakes.
There’s modular support for outputs: Outputs - devenv
5 Likes
I’d like to invite you to try https://devenv.sh, it has a much better DX than flakes.
I need to try it for sure! So far I was under the impression that it is primarily meant for developer shell environments. It’s called devenv after all. Which would exclude things like home configurations or NixOS configurations, or any other output one might wish to have really.
But maybe learning from this improved UX could serve as a guide for how to fix things upstream?
3 Likes
Alright, that makes sense. That is the kind of step you finally decide to take when thinking back to your 1200km moped trip across northern Thailand instead of hanging around here? 
But maybe the rest could take inspiration from that nonetheless and explore new avenues. It just seems to me after all this discussion here, which I read with no result or decision in sight, that the alternative between “stabilizing” flakes as is and getting rid of flakes is the wrong alternative to begin with.
But even if devenv has much better UX than flakes, it doesn’t cover all use-cases, or does it? Does Outputs in devenv mean any kind of output that I can have in a flake?
I really wished the new nix CLI outside of the nix flake command wouldn’t depend on flakes.
Flakes are imho fine. A bit rough around the edges but I still use them quite a lot. But they aren’t the only and often not the best way to do things.