module system: revert "remove types.optionSet", just deprecate #56857
Conversation
The explicit remove helped to uncover some hidden uses of `optionSet` in NixOps. However it makes life harder for end-users of NixOps - it will be impossible to deploy 19.03 systems with old NixOps, but there is no new release of NixOps with `optionSet` fixes. Also, "deprecation" process isn't well defined. Even that `optionSet` was declared "deprecated" for many years, it was never announced. Hence, I leave "deprecation" announce. Then, 3 releases after announce, we can announce removal of this feature. This type has to be removed, not `throw`-ed in runtime, because it makes some perfectly fine code to fail. For example: ``` $ nix-instantiate --eval -E '(import <nixpkgs/lib>).types' --strict trace: `types.list` is deprecated; use `types.listOf` instead error: types.optionSet is deprecated; use types.submodule instead (use '--show-trace' to show detailed location information) ```
|
I'd much rather see NixOps just cherry-pick the fix in a new release really. My intuition is that the cost of keeping technical debt in nixpkgs for 3 releases will be much higher than the cost of doing a point release for NixOps and getting that in 19.03. Is there anyone with NixOps commit rights who could take care of that? I've tried getting a hold of someone on NixOS/nixops#1088 (comment) but no replies so far. |
|
Another alternative to consider is to backport the NixOps fix in its nixpkgs derivation, which is literally a 7 LOC diff. |
|
Partially reverts 27982b4 Related issues: NixOS/nixops#1086, NixOS/nixops#1107 @delroth there is zero cost keeping this code. The performance improvement was also quite small. The evaluation issues are more serious (I like to evaluate various parts of system and this "throw" breaks strict evaluations). Though I agree new NixOps should be released more often, but let's not push them before release |
The explicit remove helped to uncover some hidden uses of `optionSet` in NixOps. However it makes life harder for end-users of NixOps - it will be impossible to deploy 19.03 systems with old NixOps, but there is no new release of NixOps with `optionSet` fixes. Also, "deprecation" process isn't well defined. Even that `optionSet` was declared "deprecated" for many years, it was never announced. Hence, I leave "deprecation" announce. Then, 3 releases after announce, we can announce removal of this feature. This type has to be removed, not `throw`-ed in runtime, because it makes some perfectly fine code to fail. For example: ``` $ nix-instantiate --eval -E '(import <nixpkgs/lib>).types' --strict trace: `types.list` is deprecated; use `types.listOf` instead error: types.optionSet is deprecated; use types.submodule instead (use '--show-trace' to show detailed location information) ```
|
@matthewbauer backported. Thanks for approving! |
The explicit remove helped to uncover some hidden uses of
optionSetin NixOps. However it makes life harder for end-users of NixOps - it will
be impossible to deploy 19.03 systems with old NixOps, but there is no
new release of NixOps with
optionSetfixes.NixOS/nixops#1088
Also, "deprecation" process isn't well defined. Even that
optionSetwasdeclared "deprecated" for many years, it was never announced. Hence, I
leave "deprecation" announce. Then, 3 releases after announce,
we can announce removal of this feature.
This type has to be removed, not
throw-ed in runtime, because it makessome perfectly fine code to fail. For example:
cc @samueldr @lheckemann @delroth (shoutout to @delroth for fixing issues in NixOps!)
This has to be backported to 19.03