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
deprecate MultiCommand
, merge into Group
#2590
Comments
To expand on why I'm not convinced that we should support flattening or merging groups, in general it's because it adds ambiguity and indirection when defining the CLI. Whether you flatten or merge, there's probably a way to get the source's callback called before its command. But there's no convenient way to merge different group's parameters, especially in the face of overlapping or conflicting parameters. It's something that any given project can make a call on, but that Click would have a hard time implementing in a generic and compatible way for all cases. |
@janluke @kdeldycke any feedback on this is appreciated |
MultiCommand
and CommandCollection
MultiCommand
and CommandCollection
, merge into Group
A search for |
MultiCommand
and CommandCollection
, merge into Group
MultiCommand
, merge into Group
I agree So if you can get rid of Just noticed you also just got rid of |
As part of rewriting the parser in #2205, I was looking at the complexities of Click's definitions and processing.
MultiCommand
andCommandCollection
could be combined withGroup
to simplify to a single way of working with multiple commands. This is a little more difficult than #2589 removingBaseCommand
.Currently, they're distinct because
Group
provides furthergroup
andcommand
decorators.MultiCommand
is the base and doesn't specify how commands are registered, andCommandCollection
"flattens" multipleMultiCommands
instead of nesting likeGroup.group
.The docs occasionally refer to "mulitcommand" instead of "group" in situations where the user would probably understand "group" better. There are very few examples in the docs of either class, and all of them can be reasonably implemented with
Group
instead.#347 (and many linked issues) show a confusion over how
CommandCollection
is supposed to work. It doesn't use each source's parameters, and doesn't invoke the source's callback before a command. In other words, currently the collection only collects the commands in each source, but users expect it to merge the behavior of all sources. I'm not entirely convinced that we should continue to support either of these things. But we could continue to support the current behavior by addingGroup.add_source
orextend_commands
with the same behavior, where the command is looked up first on the group, then on each source. In the future we could also add amerge_group
method.The text was updated successfully, but these errors were encountered: