-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
#[arg(from_global)]
with #[command(flatten)]
#5525
Comments
The challenge with Maybe one way of doing this is if
Not thrilled with having macros for such specialized cases. Also, personally I'm bothered when macros do anything besides generate a trait impl because its harder to understand what they do.
For myself, I find probably 75% (made up number) of times people discuss using globals, they are reaching for the wrong tool. They want to "DRY" their code when there isn't an inherent requirement that all subcommands have a shared argument. Instead, its only happenstance. We have this problem with cargo itself today, e.g. Of the remaining uses for globals, I somewhat question the value of |
Thank you for the quick and detailed response! I pinky-promise I do actually have a real actual use-case for global args, but that doesn't change the maths on ecosystem-wide cost/benefit.
That's good to know. As for the why: for me, it's mainly ergonomics. Slightly stronger: if all global propagation logic is handled by Given all of ^, it sounds like explicitly propagated This is an outcome I can work with! |
Please complete the following tasks
Clap Version
4.5.4
Describe your use case
Consider some global options, and some logic that reads multiple fields. Implementing this with arg-level
global
andfrom_global
attributes quickly becomes clumsy. To avoid a lot of duplication, it's useful to group these args into astruct
and place the shared logic in itsimpl
(andflatten
it into each subcommand).Currently (AFAICT) this requires one struct with
global
, and another withfrom_global
, with the fields matched up manually, including documentation (both for--help
and IDEs on thefrom_global
side). In the worst case, theimpl
also needs to be duplicated. This might look like this:The
impl
can probably be deduplicated somehow, but even so: this is clumsy and prone to drift.Describe the solution you'd like
Pipe-dream:
#[command(flatten, from_global)]
would magically, transparently transform theglobal
args intofrom_global
variants. For extra strength pipe-dream: also magically share theimpl
. I suspect this would require hooking into the globals passing machinery ofclap
such that we don't generate a newstruct
, but instead useGlobalOptions
in both sites (instead of doing this at an external-to-clap
-machinery macro level).So the above example would become:
(And then
some_command.global.some_logic()
would be valid.)This is slightly preferable to manual arg-level
from_global
s even in the absence of animpl
block, because of the automatically-synced doc comment between theglobal
andfrom_global
variant.Alternatives, if applicable
This might be asking for too much magic, maybe? If so, a less magical but still-nice solution might be (possibly not part of
clap
?) a macro that generates both theglobal
and thefrom_global
variants (with doc comments and theimpl
copied). Maybe something like:Or maybe:
This feels less neat, but hey, maybe it's the best we can get.
Additional Context
If instead the preferred way is an explicitly propagated
GlobalOptions
instance, andfrom_global
is just kinda... there, then knowing that would also be good!The text was updated successfully, but these errors were encountered: