I think you are right, but I also think your view is a bit one-sided. Flakes solve a problem, and that’s why literally everybody is using them. I don’t think it makes sense to stop supporting them.
3 Likes
Flakes ‘solve’ a problem, introduce other problems because they also tried to fix what wasn’t broken, and not literally everybody is using them
2 Likes
I agree that it was made clear that flakes are an experimental feature and people who enabled them and used them a lot (including me) signed up for… something. But considering how much has been built around flakes and for how long they stayed experimental, this something is definetely NOT crippling or removal of flakes. What I think flake users expected, is incremental breaking changes that let flakes and projects based around them evolve together to become a better version of themselves without anyone being upset that such changes are happening often and need everyone to keep up with the design evolution of flakes.
And considering that you yourself admitted to never using flakes, you might not know why they are liked by flake users and therefore can’t decide whether they are NOT part of the “nix development” that you say is forever wedged because of them.
Might be wrong on this because just like you are not using flakes, I do not use stable interfaces. But as far as I know flakes are the only thing that is developing while stable interfaces that you are using do not.
6 Likes
EDIT: softened the language, not softened the point
It is very tiring how toxic DetSys is to this ckmmunity, and how it continues to post their ads despite that.
Let me put out my opinion upfront. We had some very rough months after the open letter last year. It called for temporary ban for Eelco’s participation in community and stripping him of all formal positions.
A half-measure was done, instead: resignation from Foundation only. Well, Eelco is still around, and he’s still destructive and toxic for the project. For Nix Project to go on, this MUST be sorted out, fast. Either Eelco and his company work on their behavior - or we as a communite step up and ban them from participation, because their behavior is unwelcome.
That was the most important part. Now I just wish to respond to some interesting things in this thread.
@roberth I don’t know much about the internals of Nix Team, but I saw you giving Eelco the benefit of the doubt. You often even went the extra mile with that. It seems that this didn’t work out - which sucks. Solving things with trust is a lot less stressful than with conflict.
I’ve seen some of those betrayals of trust for a while, and I’ve campaigned to kick Eelco out of github.com/nixos/nix. Would you like to expand on problems you’ve faced and how you see the future? I feel like we could see eye to eye on that.
There’s a lot I can say about it. But the concise explanation is: it is the difference in culture. In community projects, what we call “stable” is: not a maintanence burden, reasonably feature-complete, well-tested, what constitutes a bug is clear, and bugs are treated as critical and fixed quickly. In businesses, what is called “stable” is: the customers pay and don’t threaten to stop paying.
This difference is why DetSys insists “flakes are stable”, it’s why they “stabilize” draft and problematic PRs, why they constantly play “we’d happily help but upstream is uncooperative” card. They also get to tell specific customers to enable this or that flag to fix a specific issue: they need not care about providing equally good experience to everyone, make features work with each other, or build software that is coherent.
You could take responsibility for the feature you yourself steelmanned into the open project and actually take it to completion without dismissing valid issues as “not a bug”. You could also take responsibility by facing the uncomfortable truth, that you are in a clear conflict of interest, you steelmanned a matter concerning conflict of interest, and step down.
Both of those things were avoided by Eelco for years.
I came to believe this is by design. It’s especially evident with how Graham only ever responds to posts where he can win some marketing points. It strongly rubs me the wrong way.
It can ship it under a different name, like “determinate-nix”, or “corpo-nix”, whatever they prefer. Nixpkgs ships Lix already - there’s no issue with shipping a fork under a different name.
I think what you’re referring to is something I’m guilty of, myself - doomposting out of frustration. Flake code can’t even be called a “mess” - it is of very low quality, absurdly tightly coupled and prone to breakage on sight. It was a very long way towards getting github.com/nixos/nix to 2.24 in Nixpkgs. The versions inbetween that and 2.18 had a lot of issues.
This sucks as a user of Nix, a lot. But the reason why that happened is quite complex. There were some organization issues in Nix team, testing could’ve been better. But more importantly - the changes made between those versions touched flake-related code paths. It is nigh impossible to avoid collapse when you’re touching flake-related code. Lix team made a concious decision to stay as far away as possible from flakes and focus their efforts on fixing less brittle issues - and they STILL have several flake-related bugs, some of them not fixed yet.
I’m not saying this to downplay people’s work - I hope I haven’t offended them. I’m just trying to explain how truly dire flake code is. This is one reason why people sometimes cry out, in frustration, to delete flakes. Another factor is many organizational issues around stabilizing flakes. Well, it’s beyond hard to stabilize them, when the code is so brittle - discussing design and social issues around them is very secondary to how bad the code situation is.
In short, what I’m saying is: flakes have lots of issues, fixing them is absurdly hard, and people have mounted frustrations over years of those problems. Sometimes people blow up and call for deletion of flakes. This is a radical solution - it could work, but it will probably cause more problems than it solves. It is painfully obvious, so painfully that it’s one of the factors that causes people to blow up in frustration.
What I’m trying to say is - I don’t believe anyone will actually abolish flakes, and even doing small breaking changes is a very tall order. I don’t think anyone genuinely and rationally wants to do it, either. But unfortunately, it requires a mountain of context to reach that conclusion - it took me years. It is very understandable and valid that you, not having that context, would be worried. But worry not! There are many different opinions on how to fix flakes, but I’m sure well-meaning people want to actually fix them, without making it a huge pain for users.
25 Likes
Flakes don’t have to be strictly abolished. How practical would it be to remove Flakes from Nix and develop them as an external tool in the same way npins and the like is?
I said I never added them to my workflow 
I have definitely played with them. I am a nobody in the nix community (i’d love to find the time to do more), but I manage a team with ~ 15kloc of nix for my own startup across ~ 100vms. We’ve been in production with nix for years. I don’t have any channels or state in my own personal configuration (sanix-style), and at some point we’ll probably rip channels out our prod vms to, but given that we don’t run channel updates outside of AMI building it’s never been that interesting. I do know what problems flakes purport to solve, and I know that I am solving all of those problems at industrial scale just fine with with simple pinning and function composition. I don’t feel like I am missing out at all. We don’t struggle to build anything, we are never surprised by what we build. Nix is a huge success for us.
I always find it a tad bizarre to hear people to talk about how they can’t imagine using nix without flakes, when nixpkgs scales just fine and has not a single flake in its interior.
13 Likes
They partly solve some problems. future nix should also solve these problems.
4 Likes
I don’t know what y’all are so ruffled about.
The actual value of the nix ecosystem lies in nixpkgs, and DetSys has no real influence over that part.
As long as the nixpkgs community wants to support more than one implementation, nixpkgs will be the conservative side of the ecosystem that prevents a single company from running away with the prize.
potential mea culpa
(Please don’t quote me on this in five years 
)
17 Likes
I hate that I have to ask this, but is there a place where actual (exclusively technical) discussion on flakes is supposed to happen? It sounds like a lot of people/organizations have strong opinions on the future of how flakes should be removed/changed/stabilized, so I’d imagine there would be some kind of active discussion on what is to be done, or active development on a consensus. I found this milestone for flake stabilization on the nix github, but the description, as with most other meta discussion on flakes I’ve come across, seems very defeatist. Perhaps the apathy here is why organizations like determinate systems feel like their best path forward is doing it themselves.
6 Likes
The nix flake matrix could fit but it’s filled by nixlang beginners that are very confused because they are finally using nixlang proper instead of editing configuration.nix without knowing what’s going on
The old nix cli is apparently unusable to these users and once they are using flakes they start to believe they are writing flakes every time they write a single line of nix in their whole project containing a flake.nix
I am also extremely frustrated with all the users who reason that we should block implementing a lock file mechanism in nixcpp by reasoning that they do not need/use “flakes”. I am sure they pin their deps. I am sure they wrote/use an ad-hoc script or Workflow to manage their pins.
Sometimes I think about forking and brutally renaming flake.nix to project.nix so that people stop having brainworms about a lockfile format
All the proposals for making nix non-shit (proper pure eval without flakes) are great and all but at the core of it I want a working solution distributed with nix.
If apt install nodejs can give you npm then installing nix should be able to give you a lockfile mechanism.
And having a lockfile manager built into the language distribution sure didn’t kill node’s vast family of package managers and lockfile mechanisms with all their benefits and disatvantages. I don’t see why the same cannot be possible with nix.
4 Likes
Also I don’t see why that whole inputs.follows is in any way shape or form controversial for a lockfile mechanism. It’s equivalent to overrides in npm package.json | npm Docs
I understand the frustration with the special code paths in nixcpp associated with “making flakes work” and I would love for it to have more synergistic effects on the old nix tools, I believe that there is a lot of work remaining to be done there.
Lix development channels. There’s probably other docs around and more to come in the future.
6 Likes
It has one billion update scripts for one billion hashes that are distributed throughout the repo. Bots that run these scripts. People write bots to run these script. People have put tremendous amounts of work into making nixpkgs “scale just fine”.
GitHub - nix-community/nixpkgs-update: Updating nixpkgs packages since 2018 this sure as hell did not take 0 hours. The overlap with flake update is also nonzero (but close to) but it cannot converge without executive decisions
3 Likes
followsmechanism is horrible. It is extremely rare that you want to respect downstream lockfile in practice. Let’s just not do that
It’s not a constructive proposal because it refuses to acknowledge the reality that users experience.
I think the problem boils down to dependency resolution (which is an untreated problem in Nix). Nixpkgs works well because one commit is almost one consistent view of packages. Flakes, with their deep package management treatment, goes in another direction.
IME, most of the Flakes users have troubles understanding this and are confused to why their code becomes suddenly “”“non-reproducible”“” (their wording) again because the deep dependency tree has non trivial effects on the consistent view that we had in Nixpkgs.
I understand your frustration but for me, as a maintainer of FLOSS software with Flakes, spending my time on debugging other people’s code because they did a wrong follows or they want to do something unsupported albeit impossible to communicate or encode as impossible to do, is equally frustrating.
This is why we are calling on NOT steamrolling this even though it WAS steamrolled in the past. We all want some form of hermeticity of evaluation and dependency management, but as I said: this requires HARD work. This is the size of task.
Refusing this will simply put the implementers in a dead end.
See more about this topic: Haskell for all: The golden rule of software distributions.
It’s fine to desire for Nix to raise to the challenge of SAT solving and dependency resolving. I would personally recommend that the energy budget is focused on streamlining the uncountable amount of scalability issues and technical debt that was generated by Flakes introduction (and just generic codebase debt of a 20 years old codebase, which is fine! Debt has to be paid, though.)
Of course, we can rush into trying to run without knowing how to walk (my PoV of the situation), I will pass though ;-).
11 Likes
Let’s not discuss the proposal here, IMHO, the words will be lost. Feel free to engage with the original author in DMs and maybe let’s update this with feedback. 
If you have valuable experience, go talk to the author, I’m sure they can listen and try to build something better. It’s a WIP, not what’s going to be implemented.
3 Likes
I read through the lix flake stabilization proposal and found it very interesting. The changes and ideas expressed certainly sound great, but I think I’m too much of a newcomer to nix to give any critical feedback.
I am however, once again very curious why the only place for this technical discussion (excluding this discourse topic) is in a nix fork, rather than the actual project. Is that not a massive failing on the part of the leadership of the nix organization?
3 Likes
npm’s upstreams write nodejs code and publish their code on some npm-compatible platform; nixpkgs’ upstreams do not write nix code, so many/most projects will not even accept nix files in their repo.
And even if they do accept it - how do you believe flakes will make this easier? Someone has to sit there and write the package expression at the end of the day, and keep it updated. Even if it’s just a version bump, flakes don’t have semver, version resolution, or even the ability to track tags; that’s only been implemented server-side in a proprietary detsys project.
Even if flakes had those things -I would also wonder how much of a trainwreck it’d be to have upstreams depending on nixpkgs, and then nixpkgs depend on the upstreams, and then the ensuing lockfile explosion, and the nasty 40 (? 50?)-MB tarfile becomes even more massive.(Not to mention PR merge conflict nightmares.) And using DI (follows) to even attempt to shrink the lockfile would then cause the “reproducibility” issues mentioned upthread.
Far as I can tell, flakes solves none of the problems of packaging and updating here. It’s impressive how detsys has managed to convince a large chunk of the community that flakes are magic sauce; they are not.
5 Likes
What should the org do if people say stuff like “the core of Nix is tainted by Flake” and nobody wants to constructively talk about the topic anymore
When did I say that? I’m telling you nixpkgs is not scaling for free. I’m sure improvements in the fetcher infrastructure as well as maturation of features oriented around creating locked deps from soft deps will have good effects on projects doing the same thing.
The rest is a lot of strawmanning and insults
At this point flakes.nix and flake.lock is a reserved filename with reserved semantics. Since the source code lives in nixos/nix I believe it’s not opportune to split the binaries right now. In the future nix can add or remove anything nix wants from releases, provided there is a long enough depreciation and migration period, few would be heavily impacted.
I don’t get how this helps.
1 Like