nixos/version: obfuscate stateVersion to discourage modification #80907
Conversation
Many users get the impression of having to update stateVersion when
upgrading their channel, and cause subtle or obvious breakage.
This happened repeatedly, despite nixos-generate-config adding
5 lines of comment around the definition.
Because the value of stateVersion is a NixOS version, e.g. "19.09",
people were tricked into believing this option sets the state ("system
version") of their system, when instead it sets the system version
of the state to stay compatible with.
This commit changes nothing about stateVersion itself, to ensure
backwards compatibility with uses of stateVersion inside and outside
of nixpkgs.
Instead, it now sets stateVersion to an expression that doesn't look
like a NixOS version, and should not invoke the notion of needing to be
updated.
Example configuration snippet:
system.stateVersion = lib.nixos.decodeStateVersion 2989;
Some effort is made to prevent decoding to invalid versions, but
those can still be set.
This is only for newly generated configurations, and the obfuscation
can be bypassed by just setting stateVersion to e.g. "20.03" directly,
without encoding/decoding.
tilpner
force-pushed
the
stateversion-obfuscation
branch
from
9c0f31d
to
e3c6961
Compare
|
This year, I've seen two people set stateVersion to "unstable" or "nixos-unstable", which would be caught by this with an out-of-bounds error from versions.minor. Not great, but better than silently accepting it, as NixOS currently does. I might add better error handling later. |
|
I get where you're coming from, and I've confused myself once on this front, and had the same thought; but after reading the docs and understanding what the state version actually is, it hasn't been a problem, and one nice thing about it is that if you're moving from state version 19.03 to 20.03 you know which release notes and changelogs to read for changes at least ... and have a sense of how out of date you are. It's possible the confusion from the obfuscation and complexity may be worse than the simple issue it resolves. That said I don't have a super strong opinion one way or the other. |
|
@bhipple I'm aware it's a weird "solution", to a problem you don't have. This is not supposed to help people familiar with what stateVersion does, but those who skip or misinterpret the comment above stateVersion, and end up feeling like they need to change it. And that does happen, more often than you might think. This PR was prompted by another person running into hard-to-diagnose issues that occur when you don't know what stateVersion does. Either way, something needs to improve about error handling of Being able to read changelogs is a good point, I hadn't considered that before. |
|
In Home Manager I just made the state version have an enum type, currently It doesn't fix the general problem but at least one would get a reasonable error message if one tries to put Another thing I've been contemplating is to write a file, |
|
The problem with such a stateful |
|
Not in favor of this since it makes it harder to understand the configuration (i.e. if I see Regardless, we shouldn't have 👍 on validating the value of |
|
@edolstra I agree that this makes it harder to understand what's happening. A nix repl session will quickly clear that up, but it's still weird and confusing. Changes to stateVersion are still possible, and don't need to use this encoding at all. It felt very wrong to add NixOS-specific things to lib, but I was encouraged to do so anyway. There is also |
|
I don‘t think I am qualified to weigh into the discussion, but I also don‘t think the obscuring the option will lead to better understanding of the users, which is in the end what we should be aiming that. The concept of the stateVersion is not too complicated. |
|
@infinisil My idea was that the Note, this is just a half baked idea that I have no plan of implementing anywhere but have as a backup plan in case I start getting inundated with complaints related to |
Motivation for this change
Many users get the impression of having to update stateVersion when
upgrading their channel, and cause subtle or obvious breakage.
This happened repeatedly, despite nixos-generate-config adding
5 lines of comment around the definition.
Because the value of stateVersion is a NixOS version, e.g. "19.09",
people were tricked into believing this option sets the state ("system
version") of their system, when instead it sets the system version
of the state to stay compatible with.
This commit changes nothing about stateVersion itself, to ensure
backwards compatibility with uses of stateVersion inside and outside
of nixpkgs.
Instead, it now sets stateVersion to an expression that doesn't look
like a NixOS version, and should not invoke the notion of needing to be
updated.
Example configuration snippet:
system.stateVersion = lib.nixos.decodeStateVersion 2989;
Some effort is made to prevent decoding to invalid versions, but
those can still be set.
This is only for newly generated configurations, and the obfuscation
can be bypassed by just setting stateVersion to e.g. "20.03" directly,
without encoding/decoding.
Things done
Things to question
stateVersionnewer thanconfig.system.nixos.release?lib.nixos, or ratherutils?I only discovered the new comment when I was almost done. I'm okay with this being closed,
but I still wanted to bring it up.
Related contributors
@infinisil @maralorn @nh2 @grahamc