mnapoli / silly Goto Github PK

In Symfony Console to run a sub-command is a bit verbose:

$app->command('foo', function (OutputInterface $output) use ($app) {
    $arguments = array(
        'command' => 'demo:greet',
        'name'    => 'Fabien',
        '--yell'  => true,
    );
    $app->find('demo:greet')->run(new ArrayInput($arguments), $output);

    // ...
});

It would be great to add a helper method like:

$app->runCommand('demo:greet Fabien --yell', $output)

Example:

$app->command('init', function ($input, $output) {
    $this->runCommand('db:drop --force', $output)
    $this->runCommand('db:create', $output)
    $this->runCommand('db:fixtures --verbose', $output)
});

Feel free to close this, as it may be out of scope for the project.

What are your thoughts on adding daemonization/long running process support, or something akin to that?

I've had several instances in which I've needed to daemonize a PHP script mostly because I didn't have time to learn another language to do it. I usually accomplish this using Upstart/systemd but we could do this natively in PHP using pcntl. I can't be the only one who has to do this on a semi-regular basis, so perhaps this would be a good chance to bootstrap this sort of task via Silly

Hello there!

Silly is great for quick and clean CLI apps ! So is SymfonyStyle (http://symfony.com/blog/new-in-symfony-2-8-console-style-guide) for quickly handling i/o. Right now, using it is a bit verbose:

$app->command('meh', function(InputInterface $input, OutputInterface $output){
    $io = new SymfonyStyle($input, $output);
    $io->comment('Aye aye, sir');
});

In an ideal world, i'd like to be able to:

$app->command('yeah', function (SymfonyStyle $io) {
    $io->comment('Aye aye, sir');
});

I tried to use DI for this, but it seems I cannot inject Request/Response in my service. Something like:

$pimple[SymfonyStyle::class] = function ($pimple) {
    return new SymfonyStyle($pimple['input'], $pimple['output']);
};

or like:

$pimple[SymfonyStyle::class] = function (InputInterface $input, OutputInterface $output) {
    return new SymfonyStyle($input, $output);
};

Eventually:

• Is it possible somehow to inject Request and Response in a service defined in the container ?
• Or would it make sense that Silly supports injecting SymfonyStyle directly in callables, just like Request/Response?
• Is there maybe another way to achieve what i'm trying to do?

Thanks a lot!

mnapoli/silly-php-di 1.1.0 requires php-di/php-di ~4.4 || ^5.0
php-di/php-di 5.0.0 requires php-di/invoker ~1.0
php-di/php-di 6.0.0 requires php-di/invoker ~2.0
mnapoli/silly 1.6.0 requires php-di/invoker ~2.0

This situation currently makes it impossible to use mnapoli/silly and mnapoli/silly-php-di together with php-di/php-di 5 (because of the php-di/invoker ~1.0 vs ~2.0 conflict) or php-di/php-di 6 (because of the php-di/php-di ~4.4 || ^5.0 vs ^6.0 conflict). I'm attempting to upgrade php-di/php-di because I've encountered PHP-DI/PHP-DI#377 under PHP 7.1, which appears to only be fixed in php-di/php-di 5 and above. I've submitted PHP-DI/PHP-DI#504 to address this in php-di/php-di 4, but I would still like the ability to use 5 or above.

$ composer require "php-di/php-di:^5"
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for mnapoli/silly ^1.6 -> satisfiable by mnapoli/silly[1.6.0].
    - mnapoli/silly-php-di 1.1.0 requires php-di/php-di ~4.4 || ^5.0 -> satisfiable by php-di/php-di[5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.1.0, 5.2.0, 5.2.1, 5.2.2, 5.3.0, 5.4.0, 5.4.1, 5.4.2, 5.4.3].
    - php-di/php-di 5.0.0 requires php-di/invoker ~1.0 -> satisfiable by php-di/invoker[1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.0.1 requires php-di/invoker ~1.0 -> satisfiable by php-di/invoker[1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.0.2 requires php-di/invoker ~1.0 -> satisfiable by php-di/invoker[1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.0.3 requires php-di/invoker ~1.0 -> satisfiable by php-di/invoker[1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.0.4 requires php-di/invoker ^1.0.1 -> satisfiable by php-di/invoker[1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.1.0 requires php-di/invoker ^1.0.1 -> satisfiable by php-di/invoker[1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.2.0 requires php-di/invoker ^1.1.1 -> satisfiable by php-di/invoker[1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.2.1 requires php-di/invoker ^1.1.1 -> satisfiable by php-di/invoker[1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.2.2 requires php-di/invoker ^1.1.1 -> satisfiable by php-di/invoker[1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.3.0 requires php-di/invoker ^1.1.1 -> satisfiable by php-di/invoker[1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.4.0 requires php-di/invoker ^1.3.2 -> satisfiable by php-di/invoker[1.3.2, 1.3.3].
    - php-di/php-di 5.4.1 requires php-di/invoker ^1.3.2 -> satisfiable by php-di/invoker[1.3.2, 1.3.3].
    - php-di/php-di 5.4.2 requires php-di/invoker ^1.3.2 -> satisfiable by php-di/invoker[1.3.2, 1.3.3].
    - php-di/php-di 5.4.3 requires php-di/invoker ^1.3.2 -> satisfiable by php-di/invoker[1.3.2, 1.3.3].
    - Can only install one of: php-di/invoker[2.0.0, 1.0.0].
    - Can only install one of: php-di/invoker[2.0.0, 1.0.1].
    - Can only install one of: php-di/invoker[2.0.0, 1.1.0].
    - Can only install one of: php-di/invoker[2.0.0, 1.1.1].
    - Can only install one of: php-di/invoker[2.0.0, 1.2.0].
    - Can only install one of: php-di/invoker[2.0.0, 1.3.0].
    - Can only install one of: php-di/invoker[2.0.0, 1.3.1].
    - Can only install one of: php-di/invoker[2.0.0, 1.3.2].
    - Can only install one of: php-di/invoker[2.0.0, 1.3.3].
    - mnapoli/silly 1.6.0 requires php-di/invoker ~2.0 -> satisfiable by php-di/invoker[2.0.0].
    - Installation request for mnapoli/silly-php-di ^1.1 -> satisfiable by mnapoli/silly-php-di[1.1.0].

$ composer require "php-di/php-di:^6"
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Installation request for mnapoli/silly ^1.6 -> satisfiable by mnapoli/silly[1.6.0].
    - Can only install one of: php-di/php-di[6.0.0-alpha2, 4.x-dev].
    - Can only install one of: php-di/php-di[6.0.0-alpha3, 4.x-dev].
    - mnapoli/silly-php-di 1.1.0 requires php-di/php-di ~4.4 || ^5.0 -> satisfiable by php-di/php-di[4.x-dev, 5.0.x-dev, 5.1.x-dev, 5.3.x-dev, 5.4.x-dev].
    - php-di/php-di 5.0.x-dev requires php-di/invoker ~1.0 -> satisfiable by php-di/invoker[1.0.0, 1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.1.x-dev requires php-di/invoker ^1.0.1 -> satisfiable by php-di/invoker[1.0.1, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.3.x-dev requires php-di/invoker ^1.1.1 -> satisfiable by php-di/invoker[1.1.1, 1.2.0, 1.3.0, 1.3.1, 1.3.2, 1.3.3].
    - php-di/php-di 5.4.x-dev requires php-di/invoker ^1.3.2 -> satisfiable by php-di/invoker[1.3.2, 1.3.3].
    - php-di/php-di 6.0.0-alpha1 requires php-di/invoker ^1.3.2 -> satisfiable by php-di/invoker[1.3.2, 1.3.3].
    - php-di/php-di 6.0.x-dev requires php-di/invoker ^1.3.2 -> satisfiable by php-di/invoker[1.3.2, 1.3.3].
    - Can only install one of: php-di/invoker[2.0.0, 1.0.0].
    - Can only install one of: php-di/invoker[2.0.0, 1.0.1].
    - Can only install one of: php-di/invoker[2.0.0, 1.1.0].
    - Can only install one of: php-di/invoker[2.0.0, 1.1.1].
    - Can only install one of: php-di/invoker[2.0.0, 1.2.0].
    - Can only install one of: php-di/invoker[2.0.0, 1.3.0].
    - Can only install one of: php-di/invoker[2.0.0, 1.3.1].
    - Can only install one of: php-di/invoker[2.0.0, 1.3.2].
    - Can only install one of: php-di/invoker[2.0.0, 1.3.3].
    - mnapoli/silly 1.6.0 requires php-di/invoker ~2.0 -> satisfiable by php-di/invoker[2.0.0].
    - Installation request for mnapoli/silly-php-di ^1.1 -> satisfiable by mnapoli/silly-php-di[1.1.0].
    - Installation request for php-di/php-di ^6 -> satisfiable by php-di/php-di[6.0.0-alpha1, 6.0.0-alpha2, 6.0.0-alpha3, 6.0.x-dev].

I'd find it generally useful to let Silly support Single Command Applications out of the box.

A simple way of providing this might be offering a Silly\SingleCommandApplication.
Respectively, Silly\Edition\PhpDi\SingleCommandApplication for PHP-DI.

What do you think?

$app->command(
    expression: <<<'COMMAND'
    evaluations:run
    [--id=]
    [--event=]
    [--type=]
    [--start-time=]
    [--end-time=]
    [--step=]
    [--table=]
    COMMAND,
    callable: RunEvaluations::class
);

Ends up looking like the following when using app list:

  evaluations:run                                                                                                                                                                                                                                                              
[--id=]                                                                                                                                                                                                                                                                        
[--event=]                                                                                                                                                                                                                                                                     
[--type=]                                                                                                                                                                                                                                                                      
[--start-time=]                                                                                                                                                                                                                                                                
[--end-time=]                                                                                                                                                                                                                                                                  
[--step=]                                                                                                                                                                                                                                                                      
[--table=]

When I would expect it to be:

  evaluations:run [--id=] [--event=] [--type=] [--start-time=] [--end-time=] [--step=] [--table=]

class ScanCommand
{
    // ...

    public function execute($directory)
    {
        $this->scanner->scan($directory);
    }
}

$app->command('process [directory]', ['MyApp\Command\ScanCommand', 'execute']);

When you try to use this method of injection are notified:

PHP Deprecated:  Non-static method MyApp\Command\ScanCommand::execute() should not be called statically in /vendor/mnapoli/silly/src/Application.php on line 207

And it is only with version 1.5.0

Or I do not understand?

Hi,
Silly looks amazing and faster and I want to use it instead of symfony/console but following your first page example I always get and error.

When I use this:

$app->command('greet [name] [--yell]', function ($name, $yell, OutputInterface $output) {

PHP Error log returns the following error:

PHP Catchable fatal error:  Argument 3 passed to {closure}() must be an instance of OutputInterface, instance of Symfony\Component\Console\Output\ConsoleOutput given in /Volumes/Macintosh Work/www/playground/f3-app/app/console/commands/new_package_command.php on line 8

To make this work I had to remove OutputInterface or change it with Symfony\Component\Console\Output\ConsoleOutput, is this de way to go or do you think I'm doing something wrong?

Cheers

I cannot seem to supply a default value to an option which accepts a value. Let me know if I'm misunderstanding the command definition API.

I've tried within the anonymous function's parameter definition:

$cli->command('foo [--bar=]', function($bar = 'baz') {
    var_dump($bar); // => NULL, but would expect 'baz'
});

And also with the ->defaults() method:

$cli->command('foo [--bar=]', function($bar = 'baz') {
    // ... 
})->defaults([
    // None of these work, resulting in an exception. 
    // Showing all for brevity, but I've tried each individually.
    'bar' => 'baz',
    '--bar' => 'baz',
    'bar=' => 'baz',
    '--bar=' => 'baz',
    '[bar]' => 'baz',
    '[--bar]' => 'baz',
    '[bar=]' => 'baz',
    '[--bar=]' => 'baz',
]);

PHP 7.0.7, OS X 10.11.3, silly v1.3.0

Thanks!

Tested in mnapoli/silly v1.8.2, with symfony/console v6.2.5, via laravel/valet v4.1.2.

While working on a fix for Valet, I've discovered that sub-command arguments no longer work as a result of #66. A comment on #17 appears to be the same issue I've discovered.

For context, Valet has among others the following commands link and isolate. When executing the link command, if the --isolate argument is provided, Valet will run the isolate command via Silly's Application::runCommand method:

$app->command('link [name] [--secure] [--isolate]', function ($name, $secure, $isolate) {
    # ...

    if ($isolate) {
        if (Site::phpRcVersion($name)) {
            $this->runCommand('isolate');
        } else {

If a custom name is provided for the link, it is not passed along to the isolate command which ends up using the current directory's name, which ends up causing an error because it won't find a matching link:

$app->command('isolate [phpVersion] [--site=]', function (OutputInterface $output, $phpVersion, $site = null) {
    if (! $site) {
        $site = basename(getcwd());
    }

This is what I'm attempting to fix in Valet. The solution to this is fairly simple: provide the --site= option to the isolate sub-command with the given link name:

 if (Site::phpRcVersion($name)) {
-    $this->runCommand('isolate');
+    $this->runCommand('isolate --site="'.$name.'"');
 } else {

Unfortunately, this does not work. The isolate command is executed but with no arguments.

In Silly's Application::runCommand() method, the return value of $input->getArguments() is an empty array. The reason the arguments are empty is because the input is only parsed if it has a definition. The definition is assigned to the input by the command in Symfony's Command::run() method.

The Symfony documentation, cited in #66, shows that ArrayInput is used for explicitly defined arguments. Here our arguments are defined via a string input (of tokens) which need a definition to be correctly parsed as arguments.

Reading again the quoted error message in #66, its messaging is suspiciously formulated:

Too many arguments to "xxx" command, expected arguments "yyy".

Looking up the logic behind it in Symfony's ArgvInput::parseArgument() method gives me the impression their sub-command only accepts a single argument but they are passing multiple arguments (maybe an unquoted string). That's what triggers the above error message. By adding new ArrayInput($input->getArguments(), you are skipping all arguments which "fixes" that error message.

In conclusion, Silly should revert the changes introduced by #66 in v1.8.1:

- return $command->run(new ArrayInput($input->getArguments()), $output ?: new NullOutput());
+ return $command->run($input, $output ?: new NullOutput());

The sub-command will correctly parse the given arguments from the string input.

$ php71 test.php
Fatal error: Uncaught Symfony\Component\Console\Exception\LogicException: Cannot set a default value when using InputOption::VALUE_NONE mode. in vendor/symfony/console/Input/InputOption.php:159
Stack trace:
#0 silly/vendor/mnapoli/silly/src/Command/Command.php(63): Symfony\Component\Console\Input\InputOption->setDefault(false)
#1 silly/vendor/mnapoli/silly/src/Application.php(108): Silly\Command\Command->defaults(Array)
#2 silly/test.php(20): Silly\Application->command('mail:download [...', Array)
#3 {main}
  thrown in vendor/symfony/console/Input/InputOption.php on line 159

seems to be issue with symfony 4.2:

$ composer show
mnapoli/silly             1.7.1   Silly CLI micro-framework based on Symfony Console
php-di/invoker            2.0.0   Generic and extensible callable invoker
psr/container             1.0.0   Common Container Interface (PHP FIG PSR-11)
symfony/console           v4.2.2  Symfony Console Component
symfony/contracts         v1.0.2  A set of abstractions extracted out of the Symfony components
symfony/polyfill-mbstring v1.10.0 Symfony polyfill for the Mbstring extension

Reproducer: https://gist.github.com/glensc/b28386f361db58f3c436e7b79460983b

tag v1 shows the problem:

git clone -b v1 https://gist.github.com/glensc/b28386f361db58f3c436e7b79460983b silly-51

    $app->command('greet', function () {
        return 1;
    });
    $code = $app->run();

$code will always be 0.

Hi Matthieu,

In order to update bref on a Symfony 6 project, we need to allow the symfony/console to be updated to 6.0.
I can do that but it will break compatibility with older version of PHP.

I saw this brefphp/bref#1117 and i would like to know if you prefer to still using silly or just use this PR?

Do you have a BC Policy or can i submit my PR ?

Have a great day !

How about:

• Option with an mandatory value greet --iterations=
• Option with an optional value greet --iterations=?
• Option that can be used multiple times
  (the value would be an array) greet --iterations=* or greet --iterations=+ based on optional multi-value (0..n) or mandatory multi-value (1..n).

It would be more consistent with the arguments I think.

It appears a few years ago, there was a request to apply default options via reflection on the callable CLI command, and this was implemented via PRs #25 and #26.

I'm in the process of switching over to Silly, and I'm discovering that if you have a callable that is using the __invoke magic method on a class (and thus uses the Invoker library to resolve), its default values aren't considered at all, and instead the console throws an exception that there is no value available for the specified parameter, despite there being a default value specified.

Is this something specifically to do with the __invoke-style callable, or have recent updates (i.e. with PHP-DI's Invoker library) removed this as an option?

I did notice that with PHP-DI's Slim 4 bridge, there is a specific resolver in use (Invoker\ParameterResolver\DefaultValueResolver) that performs this function. It could be that this needs to be incorporated here.

I haven't dug in enough to know exactly what's causing this, but if I can come up with a reliable solution, I will PR one in myself. :)

I've tried to use the standard Input and Output as Silly documentation says is possible, however trying to pass as 1st or second arguments fails. And I can't seem to get it to work with an optional second parameter.

Don't think the documentation is correct here.

$app->command('setenv [name]', function(InputInterface $input, OutputInterface $output) use ($myclass) {
    $name = $input->getArgument('name');
    $helper = new QuestionHelper('helper');

  ...

});

Catchable fatal error: Argument 1 passed to {closure}() must be an instance of ArgvInput, instance of Symfony\Component\Console\Input\ArgvInput given in migrate2shield.php on line 32

Here is an example of a Symfony command help:

$ app/console help help
Usage:
    help [--xml] [--format="..."] [--raw] [command_name]

This is also similar to what man pages would show.

This syntax could be reused to define the commands.

• required argument: foo
• optional argument: [foo]
• multiple arguments: [foo]* or [foo]+?
• flag: [--foo]
• option: [--foo=]
• multiple option: [--foo=]*

So, choice A:

$app->command('greet firstname [lastname] [--yell] [--format=]', function () {
    // ...
});

vs choice B (current syntax):

$app->command('greet firstname lastname? --yell --format=', function () {
    // ...
});

The current syntax is shorter, but maybe less easy to understand and remember?

Is there currently a method in Silly for adding argument and option descriptions? E.g. --yell Description: Prints output as upper case.

I know you can use [--name=]* to specify an array in the command definition. But using --name multiple times isn't practical in CLI:

$ sayhello --name=Jim --name=Shelly --name=Jerry

Would it be possible to specify the value array using space or comma delimiters?

Example:

$ sayhello --name=Jim Shelly Jerry  #space delimited array
$ sayhello --name=Jim, Shelly, Jerry #comma delimited array

trying to install Laravel/valet and I keep getting errors related to mnapoli/silly as bellow:

Problem 1
- laravel/valet v2.18.8 requires mnapoli/silly ^1.0 -> satisfiable by mnapoli/silly[1.0.0, ..., 1.7.3].
- laravel/valet[v2.18.0, ..., v2.18.7] require symfony/process ^3.0|^4.0|^5.0 -> found symfony/process[v3.0.0, ..., v3.4.47, v4.0.0, ..., v4.4.37, v5.0.0, ..., v5.4.3] but the package is fixed to v6.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- mnapoli/silly[1.0.0, ..., 1.2.0] require symfony/console ~2.6 -> found symfony/console[v2.6.0, ..., v2.8.52] but the package is fixed to v6.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- mnapoli/silly[1.3.0, ..., 1.5.1] require symfony/console ~2.6|~3.0 -> found symfony/console[v2.6.0, ..., v2.8.52, v3.0.0, ..., v3.4.47] but the package is fixed to v6.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- mnapoli/silly 1.6.0 requires symfony/console ~3.0 -> found symfony/console[v3.0.0, ..., v3.4.47] but the package is fixed to v6.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- mnapoli/silly[1.7.0, ..., 1.7.1] require symfony/console ~3.0|~4.0 -> found symfony/console[v3.0.0, ..., v3.4.47, v4.0.0, ..., v4.4.37] but the package is fixed to v6.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- mnapoli/silly[1.7.2, ..., 1.7.3] require symfony/console ~3.0|~4.0|~5.0 -> found symfony/console[v3.0.0, ..., v3.4.47, v4.0.0, ..., v4.4.37, v5.0.0, ..., v5.4.3] but the package is fixed to v6.0.3 (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
- Root composer.json requires laravel/valet ^2.18 -> satisfiable by laravel/valet[v2.18.0, ..., v2.18.8].

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.
You can also try re-running composer require with an explicit version constraint, e.g. "composer require laravel/valet:*" to figure out if any version is installable, or "composer require laravel/valet:^2.1" if you know which you need.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

I'm just trying to get started with Bref and Symfony 6, but this lib isn't compatible yet so Composer fails. I'm afraid I didn't know this lib existed until today, so I just saw that there has not been much activity lately (latest tested PHP version is 7.2, no Symfony 6, no psr/container 2, still using non-working Travis). I might be able to contribute (but haven't had a close look at the code yet), but could you please state if the lib is still supported?

In any case thanks for your work!

Hi Silly team, just reporting here that is missing Symfony 7 support to this package.

Hello,

Any thoughts on a 2.0 release that uses the PSR-11 interface directly?

Hi,

I found this library very helpful for pack/group/bundle of commands, because sometimes you want to make a simple UI for your application for tests and it get tedious to register them in classic Symfony way.

So I tried something like (all these "command packs" are simply aggregated by DI-tag; command bus returns list of events just in case it looks weird):

final class MonopolyConsole implements ConsoleCommandPack
{
    public function __construct(CommandBus $commandBus)
    {
        // ...
    }

    public function register(Application $cli, Context $context): void
    {
        $cli->command('monopoly:start players',
            function (int $players, Output $output) use ($context) {
                $gameId = $context->uuid()->uuid1();

                $this->renderResponse(
                    $output,
                    $this->commandBus->handle(
                        new StartGame($gameId, $players),
                        $context
                    )
                );
            }
        );

        $cli->command('monopoly:roll gameId playerId',
            function (string $gameId, int $playerId, Output $output) use ($context) {
                $this->renderResponse(
                    $output,
                    $this->commandBus->handle(
                        new RollDice(new GameId($gameId), $playerId),
                        $context
                    )
                );
            }
        );

        // ...
    }

    private function renderResponse(Output $output, CommandResponse $response): void
    {
        // ...
    }
}

But it doesn't work because of bindTo inside of the Silly Application.

Does it make sense to make it optional or do I miss something?

Hi!

It seems that this package does not support the alias feature of Symfony console, this is due to the fact that when calling $app->add($command) the base symfony Application parses the aliases there. After the command is returned to us, we can set aliases on them but they have no effect.

There are a couple of ways we could support this so I would like to ask your opinion before I send a PR.

1. Defer adding the command until something like ->finish() is called on the Application class. This would allow you to modify the returned command object and have it's alias take effect.
2. Add an extra optional array argument to the command method allowing you to specify the argument there.
3. Allow aliases in the expression and add some new syntax, maybe something like search,find,locate or search>find>locate. They are a bit weird but maybe you have some better ideas :)

Personally I think 1 is my favourite. 3 could technically be a BC break. I think they would all be fairly easy to implement.

Any thoughts @mnapoli ?

EDIT

Thinking about it, 1 would also be a BC break as it would require consumers to call another method. Maybe 2 is the best approach.

Currently, I can't use getHelperSet() method because I create a separate class that will be autowired by PHP-DI. So now, if I want to use getHelperSet() I have to use the old way to attach a command, by attaching a function to $app->command() second argument rather than attaching my separated class. Is there any workaround for this situation?

while single command applications are possible with setDefaultCommand:

$app->command('run', /* ... */);
$app->setDefaultCommand('run');

http://mnapoli.fr/silly/docs/command-definition.html

implemented (suggested) via: #30

it doesn't play well when you want to use arguments (not options), as that would require that you specify command name before first argument.

Arguments and options containing hyphens are matched to camelCase variables, however this does not work when specifying default parameters for those variables.

$console->command('app:import [number-of-clicks]', function ($numberOfClicks = 1) {
    var_dump($numberOfClicks); // expected 1 received null
});

This only works for an exact variable name match. Is there anything you can do about this?

Is it possible to call a command from another command?
For example, I have this commands:

package:migrate users
package:seed users

And I want to call them booth in install:app.

This is what I've tried:

$app->command('install:app', function (\Symfony\Component\Console\Output\OutputInterface $output) {
    $output->getApplication()->find('package:migrate users');
    $output->writeln("<info>New app installed with great success!</info>");
});

Thanks for your time