Repository navigation
Is there an intended way to pass modifed or added arguments from a parent parser to a one or more subparsers when using the with_annotated decorator? #1690
Description
Question / Feature Request
Is there an intended way to modify, add, or pass arguments from a parent parser to a subparser when using the with_annotated decorator?
With the with_argparse approach this is straightforward because you have access to the full namespace.
Example:
class App(Cmd):
@with_annotated(subcommand_to=parent)
def do_sub(...) -> None:
... # use possibly modified parent_argument here
@with_annotated(base_command=True)
def do_parent(parent_argument: ...) -> None:
... # possibly modify parent_argument hereI would like to use parent_argument (defined on the parent parser) in do_sub either as an argument hidden from the subparser or by accessing the full namespace of the parser.
Is ns_provider intended for this use case? If so I cannot see how.
Activity
[-]Is there an intended way to pass modifed or added arguments from a parent parser to a one or more subparsers?[/-][+]Is there an intended way to pass modifed or added arguments from a parent parser to a one or more subparsers when using the `with_annotated` decorator?[/+]KelvinChung2000 commentedon Jun 10, 2026
This not possible for now. I will see how to extend this, likely using a
parent_argumentkeyword as you suggested. But I will also need to think about how that should be typed. If done in a trivial way, it will simply become a namespace. But this defeats the purpose of having descriptive typing in the first place.I guess we want to have something like a typed dict? But how would declaring work?
neoniobium commentedon Jun 11, 2026
I'm not sure about this either.
For simply forwarding an argument, something like this might be reasonable:
For the use case where
do_parentmodifies the value ofparent_argument, I have no idea how to do this with a typed approach. I imagine argument forwarding is by far the most likely case.I still think that exposing the full Namespace of the parser (typed or untyped) inside the decorated function in a well-defined way would be useful in any case. I agree that using it excessively would fully defeat the purpose of the annotated approach. However, I think there will always be a number of fringe cases where somebody might want access to it, for debugging purposes, for example.