feature request: defopt.run add append option about defopt HOT 5 OPEN

This and #96 both seem reasonable to me, but adding a global option to defopt.run seems unsatisfying because sooner or later someone will request to be able to specify this only for some of the parameters, perhaps in some deeply nested subcommands hierarchy on top of that...

Off the top of my head, a possibly(?) better solution could be to exploit typing.Annotated here, e.g. Annotated[list[int], defopt.APPEND] here and Annotated[list[int], defopt.VARARGS] for #96. (Note that for the case here, the underlying type annotation should be list[int], not int, because that's what the type of foo would ultimately be in the program.) A PR would be welcome :-) It should also clarify how these options interact with cli_options, as introduced by #92 (which is generalizing strict_kwonly).

from defopt.

I wonder if it makes more sense to use the annotated method as suggested here or to provide a dictionary to defopt.run to indicate non-default behavior for certain parameters. This would be similar to how alternative parsers are provided as well as custom short cli arguments. It would also stick with the defopt philosophy of not changing the cli function itself, even if the Annotated solution is only in the type hint.

One potentially tricky issue to the dictionary method I've suggested is if the same argument could be passed to multiple commands with different behavior.

from defopt.

My preference would be to use Annotated. I agree with your point about not changing the CLI function itself, but Annotated is spefically designed to include "context-specific metadata" (that's what its docs say), and CLI info seems suitable there.
I am indeed worried about people requesting different customizations for identically-named args being passed to multiple functions (especially now that you added nested subcommands, which suggest that rather complex CLIs are being built).

Your point about the parsers kwarg is well-taken, but that actually predates my involvement in defopt and my personal preference is rather to use the implicitly-constructible-from-str approach whenever possible (see StrWrapper at https://defopt.readthedocs.io/en/stable/features.html#parsers).

from defopt.

Ok, so to implement this, I guess the first step is adding the functionality to properly handle Annotated. Then it seems that it could be used to solve this issue, #96, and #102. So it seems that it has a bit of value in it.

Annotated is only available in Python 3.9+.

from defopt.

We depend indirectly on typing_extensions (via typing_inspect), which brings in support for Annotated on older Pythons (in fact, we already (briefly) use Annotated internally, in defopt.signature).

from defopt.