Multiple Commands

[andyfleming]

Unless I missed this in the docs, there doesn't seem to be an easy way to set up multiple "commands". The argument parsing is nice, but it would be great to handle multiple commands with seperate argument configurations.

Commander refers to them "Git-style sub-commands".

https://www.npmjs.com/package/commander#git-style-sub-commands

Maybe the symfony/console component would be better for what I'm trying to do, but just thought I'd mention the issue to see if I'm missing something or in case it's something we'd like to add to the roadmap.

[kelunik]

This is definitely something for the roadmap, it's something I'm looking for as well. I could just remove the first argument and manually check it, but then I can't use the nice $climate->usage().

[rhukster]

👍

Would be great to have a single CLI application with multiple CLI commands in a similar manner to how Symfony CLI does it. This could be wrapped around Climate, but the as @kelunik says, it would not work well with CLImate::usage()

[duncan3dc]

I maintain a wrapper for symfony/console that adds support for CLImate as the output handler, might be of use to you: https://github.com/duncan3dc/console

[rhukster]

Starred! Thanks.

[Arcesilas]

Hi,

I wanted to wait before I post in this thread, but I've got interrogations...

I'm working on this feature and there are things I'm facing that need to be resolved, and I don't want to take decisions on my own.

There is currently no concept of Input in CLImate: the arguments are retrieved in the parser (global $argv, which is not a very good practice). They can be passed to the Parser::parse() method, but then, they are stored in the parser, which is coupled to the arguments Manager, which itself is couple to the CLImate instance. It's not a problem when handling only one command, but becomes a problem if you want to call a command from within another one: inputs need to be separated, therefore at least the arguments Manager must be decoupled from CLImate instance. The CLImate instance has the role of Output.

The problem is: refactoring how the input is handled (introducing an Input concept) may introduce some BC breaks.

I've got multiple commands already working (for now as a separate package), but it's not elegantly written:

• I've introduced a new Argument and Option classes, to be more strict with what they actually are and provide a fluent interface: these classes export the definition to a legacy Argument instance, which is redundant
• it's not yet possible to call a command from within another

My interrogations are: what if I introduce some BC break? Could it be ok to release a new major version with these changes? Should I not introduce any BC issue and restrict the changes and not allow to call commands from another command?

@duncan3dc what do you think?

[duncan3dc]

Hi @Arcesilas, I currently have a few ideas floating around for 4.0. Some of these will include BC breaks so that's not out of the question. We just need to reduce the impact of these breaks as much as possible, give people a clear/easy upgrade path

[Arcesilas]

Great! Thanks for your answer!

[Arcesilas]

Here's a very basic example of how multiple subcommands can be handled with CLImate without writing much code: https://gist.github.com/Arcesilas/06abb3b2e94f50b3bdff415b68a3213f

This example does not handle the subcommand, it simply extracts it from the arguments list.