-
Notifications
You must be signed in to change notification settings - Fork 26
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
Use a real option parser #36
Comments
+1 This will big a big step towards addressing #32.
Not yet, but I'll see I can come up with a lightweight alternative. |
what about using the symfony console component for input/output ? |
As long as it's modular/lightweight I'm all for it. I'll check it out |
That cans be a good things. Open to help one this point, just ping me. |
IMO Symfony Console is everything, but not lightview. First of all: option parsing and the things called InputInterface and OutputInterface are not the same. BTW "output": I prefer CLImate these days. |
or this: (probably this is the most robust one) |
Thank you for putting in the time to do this research. I'll check those out next week and hopefully integrate one. |
I'm all for it. Hopefully, the command line options can extend to tasks as well. Tasks often require parameters and it would be nice if there was a standard way for the task to specify which parameters are accepted, which are required, and to provide some basic validation (parameter types, for example). |
When I originally wrote
phake
I hand-rolled the command line option parser because PHP'sgetopt
functions were useless and the only alternative was to pull in half of PEAR to get access to a better one. However, we're now living in the age of Composer/Packagist, and a cursory search showed there to be a number of independently maintained possible alternatives.What are everyone's thoughts about switching to a more robust option parser? Does anybody have a preferred package?
The text was updated successfully, but these errors were encountered: