Is this the RFC you refer to? [RFC 0136] A plan to stabilize the new CLI and Flakes incrementally by Ericson2314 · Pull Request #136 · NixOS/rfcs · GitHub
And maybe this is the tracking of it? CLI stabilization effort · Issue #7701 · NixOS/nix · GitHub
Maybe that’s a thread on it Stabilising the new `nix` command line interface ?
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 flagpure-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.
EDIT: also, the nix team themselves are aware that pure-eval without flakes is a desirable feature, see these from over a year ago: 2023-09-25 Nix team meeting minutes #89 and Practical pure eval for paths in non-Flake CLIs · Issue #9329 · NixOS/nix · GitHub
Yes, you repeated what I said.
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 see why the two “blocked” any evolution of flake. since it’s there, to anyone make the effort.
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.
–flakesv2 solves the issue.
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.
There are compat shims available anyway.
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.
I must say, I think this hasn’t changed much.
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.
I have an example here search.nuschtos.de/flake.nix at f87b9bbe1cbe1117115f4efce61549b398616f82 · NuschtOS/search.nuschtos.de · GitHub which I don’t think would have happened before flakes and loading the modules is pretty uniform. Most different things come from the fact that we don’t supply modulesPath or pkgs by default.
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.
That was my problem but I resolved it by having the flake in a subdirectory and when I do nix develop or nix build I refer to the flake explicitly and use path: reference to avoid adding any files from git.
You misunderstood the issue, the issue is lack of development inputs or ability to ignore unused inputs, so to prevent lockfile explosion people must overuse follows. Those inputs still get downloaded though… And your workaround will copy .git to the store, making it even slower while not addressing the lockfile issue.
FWIW my particular complaint is about working with big codebases - it becomes really obvious with big monorepos that are hostile to using nix, so I have to do it externally - at this point you can’t really tell flakes to ignore this or that file, like it’s going to do by default for .git and whatever’s in your .gitignore (u less I’m missing something obvious there’s no way to modify how a given output is copied. It will probably be less if a problem for non-hostile monorepos, but at some point they too will become too big to work with them. I don’t think the path suggestion would’ve worked here :75 admittedly it’s been a while since I gave up and used flakes via flake-compat, amortizing the cost on input update only.
I would be happy to learn I’m an idiot and there’s an easy solution for it, but I haven’t come across one in years.
The thread title “Nix team member suggests removing flakes” is quite hyperbolic. Most people may not realize that I’m just the documentation guy. I’m not doing the heavy lifting and I can’t make or forbid anyone to do it, either. Therefore I’m not sure what warrants dragging me into the spotlight here.
Yes, as part of the maintainer team I do have elevated influence on decisions because I tend to get involved in discussions. But ultimatly the only relevant question is: Who does the work and carries the maintenance burden?
This seems to be generally agreed-upon.
Anyone can point out problems or make wishlists. What I care about is whether we can live up to our commitments – be it as the “community”, the “project”, or the “Nix maintainer team”, each of which is often (wrongly but understandibly) perceived as monolithic by outside observers.
And from two years of experience on the team, I don’t see a way to fix the design and implementation issues with flakes in (what I think would be) reasonable time, or handle the strain incurred by everything associated in a sustainable way. I also don’t believe that the additional resources the ecosystem may gain through growing adoption will help: I fear the problems will just get more, different, and harder. I don’t want to commit to carrying part of the responsibility for the resulting disappointment.
I’m convinced it would be cheaper and faster to start over by solving the uncontroversial problems Eelco tried to address with flakes independently and at the appropriate architectural layer (which may be outside of Nix to begin with). This doesn’t require removing existing functionality, but maybe calling a feature freeze, cutting scope, and adopting a very different development and communication strategy. Part of that should be clarifying authority over the various parts of the code and the associated guarantees. All this has been discussed among Nix maintainers at length. Still, someone has to do the work.
In any case, while the flakes controversy may be the most visible stain on the ecosystem, for me it’s by far not the most important one. The overall user or contributor experience won’t magically improve by removing the experimental flag. There’s a lot to unpack about the technical realities of the Nix source code and the social realities of how it is developed. Therefore I’m not sure what else to say here.
I enjoyed reading lots of insightful comments in this thread. It’s already hard to keep track of, but I’m happy to answer further questions in isolation as time allows. Please open new threads if you want something clarified that’s not evident from public record, I’ll answer there and hope so will @roberth, @Ericson2314, @tomberek, and @edolstra.
I might not fully understand the issue but here is my setup:
Project structure:
.git/
.gitignore
src/
flake.nix
flake.lock
..
My problem was that when I ran nix develop it copied everything in my src/ into the nix store for evaluation. I didn’t want that because in my case flake provided tools and didn’t need to know about my src (which was really large and on every change it needed to reevaluate everything and copied it again and again using more and more of my precious ssd).
To fix this I change project structure to (moved flake.nix to subdirectory):
.git/
.gitignore
src/
nix/flake.nix
nix/flake.lock
..
Now I can still do nix develop from root or anywhere I just need to point it to that subdirectory like this nix develop ./nix but if you do it like that you implicitly doing this nix develop git+file:./nix which will copy all files tracked by git for evaluation into the store.
To fix that I refer to the flake like this nix develop path:nix which will only copy files inside that subdirectory (flake.nix and flake.lock).
Regarding inputs.
I don’t know how to ignore unused inputs.