-
-
Notifications
You must be signed in to change notification settings - Fork 25
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
Opt-in wrapping for 3rd party commands #25
Comments
@michalbundyra — I'm really not understanding the use case and workflow for this.
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. |
@weierophinney Sorry for late response.
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. 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 ( 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:
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:
Hope it's clearer now, if not, please ping me on slack :) |
Feature Request
Summary
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:
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.
The text was updated successfully, but these errors were encountered: