Default command #2
Conversation
| @@ -56,7 +56,7 @@ class Application | ||
| private $autoExit; | ||
| private $definition; | ||
| private $helperSet; | ||
|
|
||
| private $defaultCommandName = null; |
|
pull requests should be sent to symfony/symfony. The subtree splits are marked as read-only in their description, which means that only the cron job updating them from the symfony repo writes in them. there is currently a discussion to see if it could be possible to accept pull requests coming both ways but we haven't set up the needed tools yet (or even figured if it can be done reliably) |
|
@stof Thanks for the update Given Symfony component based structure I was expecting that each component had its own repository that would be merged on Symfony, after all the components are isolated and can be used as stand alone Maybe you can take this idea to the discussion I will take the code review suggestions and do a new pull request on symfony/synfony |
|
@francodacosta It works the other way. We develop symfony in the main repo and then a cron splits the components to the individual repos. It makes the development easier as we don't need to synchronize PRs among several repos when they impact several components. We are searching a way to be able to receive PRs both ways (probably by having a tool which moves the work done in the components to the main repo) but it is not done yet |
This PR was merged into the 4.2-dev branch. Discussion ---------- Mark ExceptionInterfaces throwable #2 | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | - | License | MIT | Doc PR | - This has been reverted in beta of 4.1 because of lack of support in prophecy, which has been fixed since then (incl. release). Can be merged again. References: symfony/symfony#26702 symfony/symfony#27420 symfony/symfony#27419 phpspec/prophecy#412 ping @dunglas @ciaranmcnulty @dkarlovi @Wirone @teohhanhui @stof @nicolas-grekas @ondrejmirtes Commits ------- 17c3675226 Mark ExceptionInterfaces throwable
For stand alone applications passing a command is mandatory but most of the times not really necessary
So instead of calling my application like this
/myapp.php mycommand --my_optionI can just write./myapp.php --my_optionthis PR allows for it while allowing to add (and execute) more than one command
You just need to add
$app->setDefaultCommandName('command:name');and if the command is not found the default one will be executedincludes unit tests and does not breack BC