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.
2 Likes
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.
2 Likes
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.
20 Likes
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.
For all my flakes that are supposed to be used by end users I have code snippet examples in the readme which end users are expected to integrate into their config. Especially for the one flake I have which auto loads modules from a directory structure, it is not feasible for the average to advanced NixOS user to understand the code as it is quite complex.
Full disclosure: here’s the messages I’ve sent as a reply to the notification from this post having been hidden by community flagging. (I presumed at first it was “fork[ing] … off” that could have been seen as a play on word, but it was genuinely about a fork.)
I'll need some guidance to know how this is inappropriate and how it could be made appropriate.
Any update?
Like I said previously, I don’t know what makes this inappropriate, and can only guess that enough people have determined that this was a good way to make a post they disagreed with go away, instead of seeing actual inappropriate behaviour.
- The post was not offensive.
- The post was strongly worded, but not abusive, especially considering the continued context.
- There was absolutely no hateful context.
- I don’t believe it was against the community guidelines.
If there is any doubt, this is my genuine belief: everyone would benefit from Flakes being a plugin. I am on record saying this to many people at many point in time from basically the moment Flakes were introduced.
And saying that using the excuse that the plugin system is insufficient is a pitiful excuse is also my genuine belief. The plugin system is incomplete if one cannot implement the different independent features that makes “Flakes” with it.
What else is there? Do I have to remove the line about VC quarterlies or whatevers? Because this is also my genuine belief that the push from Graham to “just mark Flakes stable" is coming from factors he is not being genuine about.
And then finally, is this about my representation from Graham’s insistence around Flakes being made stable at any cost as “bullying”? What is it if it isn’t that? Someone is using pressure on many platforms on the Nix team to force a result. Is there a politically correct term I should be using?
Am I missing something else?
Is it because I’m now an outsider?
What?
¯\_(ツ)_/¯
3 Likes
I’m in that dataset yet I dislike flakes. I agree with Infinisil’s objections (and more), I wish we would redesign them completely. Yet I add a flake.nix to all my new projects. Why? Because what alternative is there right now? Flakes have sucked all the oxygen out of the room for any alternatives. So I begrudgingly go along with it all. But please don’t count my acquiescence as endorsement.
@grahamc you count the number of flake users as an endorsement: I think that’s survivorship bias and circular reasoning. You’re not counting:
- the projects which would be using Nix if there were a better alternative to flakes, but didn’t because both default.nix and flake.nix are still too poorly designed for them
- the people who use flakes because they prefer it to default.nix but actually dislike flakes and want a better alternative
An article linked upthread covers this exact problem: Nix Flakes is an experiment that did too much at once… — Samuel Dionne-Riel
The central thesis of that post is that flakes hamper the development of better solutions. In that context, counting flake usage as endorsement is not fair. What alternatives do we have?
8 Likes