Revert "nixos: rename system.{stateVersion,defaultChannel} -> system.nixos.\1" #44107
Conversation
…nixos.\1" This reverts commit 095fe5b. Pointless renames considered harmful. All they do is force people to spend extra work updating their configs for no benefit, and hindering the ability to switch between unstable and stable versions of NixOS. Like, what was the value of having the "nixos." there? I mean, by definition anything in a NixOS module has something to do with NixOS...
See the previous commit for motivation.
|
Could have mentioned me here... Seriously, can we get the mention bot back? This is not the first time something I find useful is reverted and I get "notified" only by a broken evaluation after a rebase.
Motivation behind 095fe5b:
- `system` namespace is overloaded, I think having those under `nixos` makes the manual easier to read;
- while `defaultChannel` is IMO kinda okay on the top level semantically, `stateVersion` IMO is not: `stateVersion` is a very `nixos`-specific thing; `slnos`, for instance, does monoidal services and they have their own monoidal way to do versioning; when using `nixos` modules in `slnos` it makes sense to clearly separate those;
- note however, that the only use of `defaultChannel` in `nixos` tree (in `shells.nix`) is `nixos`-specific too (neither `slnos`, nor `nixops`, strictly speaking, use `nixos-rebuild`);
hence that patch.
I'd liked this to go even further: `system.copySystemConfiguration` to be moved under `system.nixos` too, `system.nixos` to become simply `nixos` and `system.autoUpdate` to become `service.nixosAutoUpdate` or something, this way `system` namespace would've become, literally, "a namespace for very low-level system things", not a mashup it is now.
But if you're like "meh, who cares about composing nixos with obscure projects and keeping the option namespaces structured", then fine, I can just revert the revert in SLNOS =/, but I think that at the very least 095fe5b was not "a useless rename".
|
|
Making names more intuitive helps newcomers to learn, understand and also memorize NixOS and Nixpkgs easier. That's an important value proposition for such changes. Attributes shouldn't be just removed or repurposed, of course. |
|
Well, yes, but every change comes with a price and risks paid by current users. In this case I'm not convinced the improvement is significant enough, though I would probably choose to put these two together with the other |
|
I'm annoyed that I have to change my stuff twice, because somebody didn't want to change his once. I can't be the only one. I'd also like to see better justification for reverting something that's been in place almost 4 months. Next time, can we put in the deprecation warning + aliases, then schedule the actual deprecation as part of the 18.09 release? That way, you all have a solid 6 months to quarrel about it, without catching innocent bystanders in the crossfire. |
The previous naming was in place for almost three years (since the 15.09 release). This restores the situation back to that.
Well, the thing is that (IMHO) these sort of changes shouldn't have been merged in the first place without going through the RFC process (given that the proposed changes essentially require every single NixOS user to modify their configs, I feel that is appropriate) where the concerns of deprecation warning + aliases could be raised. But there is essentially no enforcement on making people actually do that. So currently reverts seem to be the only counter to this current trend where anybody can break existing stuff as they want based on justifications like "[some thing] is not even something I think we should have" or "I just don't care about backwards compatibility as much". |
|
@vcunat
By that logic nothing should be changed unless it has some deep technical reason. Personally, I think order > chaos, nixpkgs has enough of chaos already, since option naming influences documentation directly I think saner option names are a must.
@dezgeg
through the RFC process
Yay! RFC Bingo!
Let me remind you that there's not a single one accepted technical RFC, and RFC's get less reviewers on average than similarly long-standing PRs.
If you search stalled and closed PRs with "RFC" text in them you'll find that there's like a whole lot of very cool ones. (I often feel that I just need to bite the bullet and cleanup and publish SLNOS branch that adopts them, but then I get lazy.)
... reverts seem to be the only counter to this current trend where anybody can break existing stuff ...
Right. But does that actually happen? Do those people really break stuff intentionally? Did _the PR in question_ break anything? I don't think so.
|
|
Let me remind you that there's not a single one accepted technical RFC, and RFC's get less reviewers on average than similarly long-standing PRs.
Fortunately, by now that has stopped being formally true.
But yes, I agree that recommending to put option naming into RFC process is can lead either to nothing or to the RFC process being even harder to clean up and push forward (because of mixed scale). We have bigger (literally) things to put there…
|
|
Regardless of ones opinion of the revert, this was merged far too quickly. |
|
Maybe we can keep both, without deprecations, just like do with I'm more in favor of keeping NixOS "experimental" in option naming. Let the option namings evolve. |
This reverts commit 095fe5b.
Pointless renames considered harmful. All they do is force people to spend extra work updating their configs for no benefit, and hinder the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by definition anything in a NixOS module has something to do with NixOS...