Everybody talks about how we needn’t have stateVersion at all, they’ve been talking about that for a long time, but in practice that future isn’t becoming a reality.
This proposal makes it less opaque to the more compentent among users, could potentially be leveraged in CI checks to actually push the existing nixos codebase toward using it less, and could also be leveraged, once conversion was complete, to allow not setting system.stateVersionif the config doesn’t enable any modules which require it. That would remove a significant amount of the issue in itself.
This isn’t either/or with getting rid of stateVersion, it’s the start a viable upgrade path toward that goal, if that goal turns out to be achievable, which also has immediate benefits, whether the goal turns out to be achievable or not. I’m all for it.
Well, yeah… it requires some work to make it happen, and everyone has limited time, myself included. That applies to this proposal too.
I’m not trying to make perfect the enemy or the good, here: I’m saying that in my view the proposed change is more of a lateral move, and that we have the ability to significantly reduce or even eliminate the option with the tools we already have, which I believe would be a comparable amount of work. Both would involve documenting new conventions, spreading knowledge of them among contributors and reviewers, probably adding ratchet checks to ensure monotonic progress, and going through all the existing uses to migrate them.
By default nothing will happen unless someone is motivated to address the problem. If they are, my suggestion is that the same amount of work could deliver greater benefit by moving more directly in the direction of dropping system.stateVersion, while avoiding the drawbacks of encouraging more unnecessary uses of it and increasing the likelihood that people break their systems for little to no benefit by contradicting our general warnings against bumping the value. Implementing a ratchet check to discourage new uses of system.stateVersion entirely should also be easier than requiring it to be used in a specific form.
This is already possible; we do it in Nixpkgs.
To be clear if I thought it was a open research problem to figure out a good way to kill the option off I wouldn’t be suggesting this. I just don’t believe that’s the case; it’s rather a “nobody who cares about the issue and knows how to fix it is putting in the time to do so” thing. We could avoid adding the vast majority of new uses in Nixpkgs immediately, things like conditional package options could be made mandatory with minimal churn, and I’d estimate there’d be maybe five in-tree uses that would require some careful thought to handle after the rest are incrementally addressed.
A proper edition system and migration tooling would be very nice and important in the long run (we already have pain from being unable to do good gradual rollouts of experimental functionality, and as users are well aware our deprecation process is often not the most graceful) but it’s not required to address something that causes a lot of user pain from only a few dozen instances.
A proposal like this needs a beachhead. Emily has convinced me that the beachhead I thought would be suitable would be better served by not using stateVersion at all, since the replacement is approximately a one-liner. When it is cheap, not using stateVersion is preferable to per-module stateVersion, which itself is preferable to using system.stateVersion directly. (Emily seems to think that the second comparison is ‘lateral’, but I’m not going to pick that fight right now.)
So my current plan is to table this proposal while I implement Emily’s fix for the Seerr case and document it (which I can do without a whole discussion, I think), and repeat that until I find a use of stateVersion that wouldn’t be a one-liner to fix, at which point I’ll bring it back here for someone to show me how that situation should be resolved. And when the answer to that question becomes, ‘Well, you should write this big thing that nobody has the time to write,’ that’s when I’ll pick this proposal up again.
Edit: previously contained a reaction to @llakala’s comment that was, I now think, unjustified.
A migration like this should probably be done in two steps, as an immediate problem with this is that the current service isn’t forwards compatible, and will break on a rollback.
Sorry - to be clear, that was a joke referencing the fact that many long-standing issues in nixpkgs persist for similar reasons. The motivation is often what blocks fixes, not a plan. I agree with Emily’s summary of the situation.