Opt-in wrapping for 3rd party commands

[michalbundyra]

Feature Request

Q	A
New Feature	yes

Summary

Suggested before in #20 (comment).

As we would like provide integration layer with many libraries where console commands are already implemented (lets consider for example doctrine-migrations) we might want provide additional 'opt-in wrapping' so these commands can behave the same way as our commands - in case of input params and interactive mode.

In general it shouldn't be difficult to accomplish as long as we have array parameters (multiple values) - see #23 and command does have unique names for arguments and options.

In case command use the same name for argument and option, we may want provide additional mapping for parameter names, for example:

my-command <name> --name=<opt-name>

the configuration will be something like:

'laminas-cli' => [
    'wrapped' => [
        'my-command' => [ // or command class name
            'name' => '--arg-name',
            '--name' => '--opt-name',
        ],
    ],
],

when mapping is not provided the same names will be used, but arguments will be converted to options.

Because of this wrapping provided options of parameters can be passed to commands in chains.
Also we have consistent interface for all commands in laminas-cli.

EDIT:

As I am thinking about it more, probably we would need a bit more extended configuration. In the options/arguments mapping we would need provide also what input param type we want to use, maybe also if the parameter should be required.

[weierophinney]

@michalbundyra — I'm really not understanding the use case and workflow for this.

• Is this for use when chaining third-party commands?
• Is this for use when attaching third-party commands to laminas-cli as top-level commands?

You mention specifically doctrine-migrations. That library already uses symfony/console, so what behaviour would differ from laminas-cli, exactly? Are you thinking of converting input options into laminas-cli input params? Why would we do that instead of using input mapper configuration — is it to allow prompting for options that need to be provided by the user?

Basically, I'd like to see an example of what you'd like to accomplish: a command setup (including chains, if warranted), and an explanation of what functionality you cannot achieve currently, and how you envision achieving it. I have some ... ideas ... but without a concrete example, I might implement something entirely different.

[michalbundyra]

@weierophinney Sorry for late response.

• Is this for use when chaining third-party commands?
• Is this for use when attaching third-party commands to laminas-cli as top-level commands?

Actually for both.

My whole point here is to deliver the same user experience and interface for all 3rd-party commands we want to integrate.
If we have (let say again doctrine-migration) we should create probably "laminas-doctrine-migration" with module/config provider where we register commands and provide default configuration so migrations works out of the box.

Then all commands used in laminas-cli should be available to use in chains, and it is only possible when we are using our "input parameters" instead of symfony options/arguments (setting back the answer so it can be pass to next command in the chain).

I do not have ready solution here - I haven't tried anything like that, so we should first try if it is possible, to wrap somehow 3rd-party commands, so all options/arguments are rewritten to our input parameters and commands can be used just "by-nane" and all questions will be asked during execution.

I was thinking about very thin, generic wrapper, so we do not need to create wrapper for every command with super user-friendly questions for parameters. We can ask just "what should be the value of 'xyz' parameter?", or ... maybe we can add questions also in wrapper configuration (param name => {question, type of param}).

Again, my goal here is that we have the same interface for all commands, all commands can be used in chains (anywhere, as first-level - so other can be attached to it), or as n-level - so our command or 3rd-party command with our wrapper can be attached to any user-defined-laminas-cli-compatible command. So "our wrapper" should do all magic inside to convert "out inout params" <-> "symfony input options and args".

As a very basic example I want this to be possible:

- my-custom-command
| - doctrine:migrations:migrate
  | - my-other-command

So I can define chain where "3rd-party command" is in the chain (it does not matter if it is on top or in the middle).

Right now it would not work for couple reasons:

• required arguments (if 3rd-party commands defines any arguments)
• passing params values from previous command to the next (to and from 3rd-party command)

Hope it's clearer now, if not, please ping me on slack :)