Closed wfchandler closed 2 months ago
Customer report from https://oxidecomputer.slack.com/archives/C06QW63CYPM/p1723121576190879?thread_ts=1723121438.371029&cid=C06QW63CYPM
The potential downside of this change is that it would prevent us from creating a --profile
argument for a subcommand. None exist currently, and it seems like a bad idea to do so.
I am in favor of this — it came up on the original PR:
https://github.com/oxidecomputer/oxide.rs/pull/727#issuecomment-2229151073
A small downside is that it adds noise to the docs by adding --profile
to every command, but we can fix that by adding a global
flag to each arg like I'm doing with required
in https://github.com/oxidecomputer/oxide.rs/pull/725, and then the docs site has to handle that. But I don't think we should block this change on that, we can do this and then fix that.
I should note that I also have no problem hacking a fix into the docs site by hard coding a special case for the profile arg. Ideally temporarily, but it's so simple that it doesn't matter that much.
I think the upside of having it be allowed at any level is worth the extra text within the options flags outputs. Also agreed that it is a small downside to have it repeated on the docs, but certainly not worth blocking on.
I'm not sure how much custom work it would be to have global arguments that did not appear this way within clap.
The
profile
argument is associated with the top-leveloxide
command, meaning it must be applied before a subcommand is registered. It would be convenient to be able to specify this arg at any point in the command, such as when repeating the same command against different profiles.Set
global
totrue
forprofile
to allow this behavior.