Amazing work with the survey! Very cool to see all this data.
This is ridiculous at this point. To the community, please vote for candidates that will without reservation make the relevant Nix flags true by default for the next Steering Committee election.
There is no reason to sandbag this further. I think it’s far beyond a issue that will just resolve itself at the team level at this point.
@cafkafk how should the Nix team communicate the very different levels of interface stability and evaluation reproducibility between Nix proper and its Flakes shell?
Or do you want to further burden the team with maintaining various compatibility levels? They can barely address the significant shortcomings of Flakes even without that burden. The nature of the project makes it so that many fixes can realistically only be breaking changes. History shows this, but also that those changes have not tended to affect many users so far.
If anything, I personally would rather see the Nix team finally take advantage of the experimental status and at least try to address some of the problems flakes have. One can dream.
Indeed. Time for CppNix to declare Flakes deprecated.
Considering just how much stuff is broken, untested, inconsistent, undocumented and poorly wired together still, I’d consider this to be a very poor technical decision at this time. If anybody is willing to step up, put in the work to help (pardon my French) shovel the metric tons of shit in the codebase I’d be in favor. Sadly, as it stands the progress on that has been quite poor even considering the tons of shit already shoveled. (This is me talking from my experience being on the Nix team for ~1 year and also shovelling a fair share).
Also, why the hell does SC not talk to the nix team proper at all about such things? What’s the end game there? Plonk down a favourable SC vote and wave your magic wand? Or issue a royal decree? I’m not following.
One thing I can certainly agree that we’re far behind in formalising — the already followed consensus of the universally understood truth — flakes are ossified enough that any major changes would reflect very negatively on the community, which is already torn between 3 forks with increasing divergence in all areas.
How about we start with something much smaller and tangible (yet unsurprisingly also out of reach):
Working towards formalising a langref of nix the language, while getting all the implementations together. That’s a no-brainer prerequisite for stabilising anything IMO. There’s so much interaction between flakes, filesystem semantics, the store layer that to ensure consistency we absolutely need that figured out first.
In general, I’m increasingly disappointed by the amount of cargo-culting going on.
Hey hey hey slow down! That’s a double bind between two strawmen, neither of which I picked!
I’ve already made my ask very clear before
We keep getting messages about flakes not being stabilized, and my efforts to push this issue seems to be met with various attempts at stalling. It is my belief that regardless of how we phrase it, de facto, flakes are a stable, if imperfect feature, used everywhere, and a major selling point of Nix. I think we should move immediately to declaring flakes stable and shipping them as such. I don’t think there are any valid reasons to delay any longer, it is a constant source of harm on the project, and it doesn’t win us anything other than mistrust and reputational harm.
I wouldn’t mind at this point, at least that would be a very strong start. It’s as if we ignore that 3/7th of the Steering Committee has a strong mind share with the Nix team already, with 2/7th being on the team.
That said, it’s extremely simple: the only actual difference between flakes being “unstable” and them being “stable” means that flakes are no longer opt in, but on by default, leading effectively to no behavior change.
The community, as PROVEN by the survey has a vast majority that uses this feature, the commercial interests all use it. The major reason we lose users to Determinate Systems is they enable it by default.
THERE WOULD BE NO EFFECTIVE DIFFERENCE FOR THE 78.9% OF USERS THAT ALREADY DO THIS EXCEPT LESS FRICTION FROM TURNING IT ON.
By turning it on, the only thing that will change is we no longer pretend that a system that is being used by the vast majority of companies and users is somehow unstable. I think this will only lead to stronger stabilization efforts.
I wouldn’t stop you, this can be done on the side. There are still 78.9% of users using flakes, that situation still has to be dealt with, and none of this is a good reason for delaying that.
If anything, I think moving more in a direction where decisions get made instead of delayed behind countless roadmaps, i.e. sandbagging, would lead to the Nix team being more competitive.
Ultimately, I think that whether the Nix team sees this need, it is nonetheless a real need in both the private userbase and the commercial one, and so far, none of these ideas that “if we only had xyz, THEN we could stabilize flakes” has lead to it happening. The barriers that are mentioned are always ones that are effectively irrelevant, except for perhaps a theoretical 18.1% of users, who I suspect would avoid the feature anyway if they have strong opinions about this.
Also, fair’s fair: I get why people are apprehensive. Nobody wants their name on the commit that says “yeah this won’t break”. Especially with something that touches this much surface area.
But honestly, I don’t think that apprehension is free. I think it’s a big part of why this is still a mess. If you can’t fix something properly because it’s unstable, and you won’t stabilize it because it’s not fixed properly, you’re effectively stuck in a cycle. Nobody has to do the boring work of pinning down store/eval semantics on a deadline, because there isn’t one. And nobody really treats flakes like production software, because on paper it still isn’t.
Breaking those kinds of cycles is the kind of things that is under the Steering Committees mandate.
So when the objection is basically “we haven’t earned the right to touch this yet” I don’t buy that as a technical argument anymore. It’s a permission structure with no exit criteria, and permission structures with no exit criteria just run forever. “We don’t want to own this yet” I can actually work with. But all of the the arguments that are just “it’s still bad” seem to be self enforcing, because if we reason out the consequences we’ll end up right back where we are right now, and they’ll still be bad.
If the SC started telling the systemd team how to maintain systemd by decree, I’d leave. You’re going to kill a lot of interest from stakeholders if you make it the norm for the SC to just decide things on behalf of the teams who supposedly have agency in their domains. That kind of thing is exactly why most of the moderation team resigned last year.
It’s very inverted here, because before I joined that was the norm, and i’ve steered strongly against that. This is one of the few issues that have been locked up for so long that it seems like the exact type of problem we should be engaging with like this.
We still can’t force the hand of the Nix team. And I wouldn’t want to literally force it. But I would be fine with the royal decree that says they’re stable now, and I would be fine with evaluating other implementations against the criteria that we ultimately want a implementation of Nix with stable flakes.
This would also make it easier to justify e.g. sending grant money that way, seeing GSOC projects that work to improve the quality of an actually shipped flakes etc..
And to be expressively clear, this is all operating under my assumption that the Nix team is actually interested in stabilizing flakes, even if they dislike the specific route I’m proposing. If the notion is that the Nix team is literally against the idea of flakes (which so far doesn’t seem to be the case, at least in aggregate), then that’s again a very different discussion, and one I think it’s about time we had, instead of just punting it forward.
We do not have information on why people are using Determinate Systems Nix. This information was not gathered in the survey. And Nix is still the dominant implementation used by a very wide margin picked by 87.5% of the respondents. Lix has a lead on Determinate Systems Nix even though the Lix core team placed the experimental Flake feature set and semantics into a “feature freeze.” But again, this does not tell us anything about why people are picking Lix or Determinate Systems Nix. You cannot infer conclusions based on information you do not have.
As I said several times by now, flakes have still several serious issues that haven’t been really resolved, and to do so will need large breaking changes. I agree that the situation is kind of ridiculous, particularly with the state of the Nix CLI, but declaring flake stable won’t magically solve these issue, it will probably complicates things further: you would be breaking stable features in addition to experimental ones.
For me the biggest unresolved problems are these: the surprising behaviour of copying the working tree to the Nix store, that has many practical and also security implications (#4097) and the complete lack of inputs, not even as cli flags (#5663). Other people with more complex needs will probably have more issue.
That is true (tautologically), but what I can say is that I know why companies I’ve had contact with have decided to pick it. All of the commercial actors that I’ve had contact with were largely funneled into the Determiante Systems ecosystem via the ease of installing flakes, and then often start to fall off around the point where the gains of lazy trees and other promises fall flat or stay on Determinate Systems because that’s what they already have.
A worthwhile thing to note is that simply being the first thing installed often is a very powerful retention mechanism in play here, but I digress.
So that isn’t purely based on survey data, but also on my anecdotal understanding of various corporate entities I’ve been in contact with, and had a chance to talk with.
I fail to see that there would be any codepaths that exist currently that would be broken. The only difference is that things that before required an additional flag to run certain commands, that 79.1% of the participants of the survey enable anyways, would no longer require that flag.
I fail to see how any specific behavior that wasn’t enabled purely from that exercise would break, anything that already exist and works and isn’t gated behind that flag should not break from removing it.
And all the commercial actors I know who are in the Determinate Systems ecosystem are there for reasons entirely unrelated to flakes. But that’s anecdata too, which is exactly the point. Our anecdotes point in opposite directions, and there’s no way to weigh one against the other. Neither of them can support a claim like “the major reason we lose users to Determinate Systems is they enable it by default,” stated as fact in an argument for changing project policy.
More to the point, Determinate Systems shouldn’t be the motivation here at all. The goal isn’t to stabilize flakes as a competitive response to another distribution. It’s to give the Nix team the room to make Nix good, correct, and something they can sustainably maintain.
So true. I totally get that flakes are not “done”, the implementation a mess etc. But now it feels any random change in semantics can be excused by “it’s experimental”. Lix freezing flakes makes it imho a more dependable basis for using flakes. 
So I’d welcome declaring it “on-by-default” because the current situation is just unexplainable to newcomers and a significant source of friction because the complete ecosystem uses flakes. I don’t see any downside. People depend on it already. It’s de facto stable regardless of what we would hope for.
Yes anyone can just say anything. My specific role in the project would be ill fitted to someone that wasn’t willing to go beyond that and make judgment calls based on what is actually the experienced ground reality before it was codified with a year-long lead time into a survey.
Your following reason:
All the more support that that is a footnote to my core claim anyway, because if Determinate Systems doesn’t matter, then neither does the anecdotes, whether or not they hold up.
I agree. Albeit, others have made the point that there are already other competing forks, so my response was never to the claim “what is the sole motivating reason for stabilizing flakes”, but rather rebutting the implicit idea that my version of stabilization would lead to more forks.
I think we should declare them “production-ready” but not “stable”.
In my understanding/experience, while you may hit the limitations of flakes at “development”/configuration/build time, the resulting systems/artifacts are fine. That seems feasible and reasonable to document: the flakes interface, syntax and behavior may still change between versions/variants of Nix, but the end-result is OK to be used in the ‘real world’.
My impression is that this would not add much additional burden, as it’s effectively what we’re doing already, just not said out loud so far?
I think the difficulty is actually not on the Nix side ‘technically’, but in the documentation: even with Flakes “production-ready”, I’m pretty sure we don’t want to deprecate the classic interfaces. So what do we show in the docs? So far we’ve had the excuse “flakes are experimental so we show the classic interfaces in the docs”. Do we now mix them? Show both everywhere? Have two versions of every doc? Show only flakes? All of these sound painful. (I haven’t followed if the Documentation team has any plan here, possibly they have)
Flakes can’t be fixed properly not because they are unstable but because they are full of issues to fix and that’s a lot of work to fix all of this and Nix team makes progress on some of the innumerable facets of this absolute mess.
The definition of production-ready that Nix uses up to now is about plausibly succesful effort at reproducible behaviour, and I am almost sure that fixing issues with flakes will lead to evaluation changes a few times.
So you argue for Nix dropping stability promises. Because eventually Nix team will refuse to maintain some misbehaviour of Flakes going forward.
There are no flakes in Ba Sing Se.
I’m one of the people that voted in that survey and a flake user that would very much like them to be improved.
I would not want them to be declared stable in the current state and especially not against the will of the people responsible for the code.
What would declaring them “stable” change?
If the percentage of the user base that is already using them is this high when they’re opt-in and the people responsible for the actual code don’t want to declare it stable, who benefits? The small remaining percentage of people that see it as a sign to finally switch, switch. Now we have up to a hundred percent flake users.
Does that make anything easier, for anyone? Wouldn’t change anything for me, right? Best benefits I can see are:
nix.settings.experimental-features = "nix-command flakes";.This is an honest question. If declaring them stable would somehow actually remove roadblocks, that would be wonderful.
My personal anecdotal experience is that people mainly care about lock files. They are used to them because they came into Nix via tutorials and feel like they are a natural fit for NixOS.
From that perspective, it can feel like the people arguing against flakes want them to lose lock files, which of course feels like a straight downgrade.
I think as long as a lock file of some sort remains, people would be fine with quite drastic changes.
From the sidelines, it looks like flakes are this huge mess that was pushed through in the past. People are already using it, making a clean re-start really difficult, even though it would be very much appreciated.
Everybody is drained and fed-up and just wants to be done with this.
After having written all this, I can understand the people that want to throw out flakes much better. Something I didn’t come into this discussion with.
I can also understand the people wanting to just declare them stable to be finally done with the conversation.
What a mess
At present flakes are the best solution people have to solve certain problems. If somebody was able to come with with a better solution that addresses the short falls in flakes and has general community agreement, I think I lot of people would seriously consider migrating over.
I am not convinced we have to ditch flakes to solve the short falls though… I might be wrong here, I haven’t looked at the code in depth.