-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Make sure to backport to 19.03.
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! |
…#56857) 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) ```
…#56857) 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) ```
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.NixOS/nixops#1088
Also, "deprecation" process isn't well defined. Even that
optionSet
wasdeclared "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