Punt on improper global flags for now#7610
Conversation
|
Let's please not do this kind of massive code churn when we could just stabilize the |
|
Let's keep this open until we've discussed your one big flip alternative. It's hardly massive, anyways, and the infrastructure is useful for further experimental features, like CA derivations, which could need its own command or flags. There are a number issues with the new CLI that need fixing that we have not discussed yet. When you open your PR I will start commenting on them. |
|
Also if we were to stabilize everything then we we would need a proper fix for these flags being accepted by all commands, which is terrible UX. That is far more work. |
|
Because this depends on other PRs the diff is confusing so I will mark as draft now. CI has run (which I don't think it does for draft PRs) so that's good. |
|
🎉 All dependencies have been resolved ! |
See the note in the test. We don't want these flags showing up for commands where they are irrelevant. Eventually, this needs a proper fix, but it need not be a blocker for stabilize: for a quick-n-dirty punt, just put these flags behind the `nix-command` unstable feature. This is fine because they are only relevant for commands which we don't need to stabilize for a while.
7f3267c to
7c4dea3
Compare
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
See the note in the test.
We don't want these flags showing up for commands where they are irrelevant.
Eventually, this needs a proper fix, but it need not be a blocker for
stabilize: for a quick-n-dirty punt, just put these flags behind the
nix-commandunstable feature.This is fine because they are only relevant for commands which we don't need to stabilize for a while.
Depends on #7609
This PR proper is just the final commit in the chain
Resolves #7820 vis-à-vis stabilization in the short term.