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?

[neoniobium]

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 here

I 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.

[KelvinChung2000]

This not possible for now. I will see how to extend this, likely using a parent_argument keyword 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]

I'm not sure about this either.

For simply forwarding an argument, something like this might be reasonable:

class App(Cmd):

    @with_annotated(subcommand_to=parent)
    def do_sub(..., parent_argument: Annotated[..., Argument(from_parser="parent")]) -> None:
        ...

    @with_annotated(base_command=True)
    def do_parent(..., parent_argument: ...) -> None:
        ...  # possibly modify parent_argument here

For the use case where do_parent modifies the value of parent_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.