Silly CLI micro-framework based on Symfony Console

This PR aims to update symfony/console version in order to make it work for brefphp/bref in ref of #60

I have updated to a newer version of phpunit in a separated commit too

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?

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.

$ 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

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

This PR brings support to set descriptions and default values:

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

$app->defaults('greet', [
    'firstname' => 'John',
    'lastname'  => 'Doe',
]);

$app->descriptions('greet', 'Greet someone', [
    'name'   => 'Who do you want to greet?',
    '--yell' => 'If set, the task will yell in uppercase letters',
]);

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?

Currently, it is not possible specify a argument or option name with a hyphen in it (e.g. --dry-run) and have that match a parameter name in the callable like $dryRun.

This is unfortunate because multi-word options are a quite common occurrence in tools. e.x. the version of rsync I have installed has 57 (!) multi-word options and 39 of those are not aliased.

Also, in some cases (like --dry-run) the wording used is quite common so that's what would be reached for first.

I took some time to create a resolver that will un-hyphenate and lowercase the names before matching against closure parameters to solve this issue.

I saw #21 after I ran into a need for this today.

• Default parameters will now also be determined via reflection.
• Setting defaults via ->defaults(…) will now set defaults for matching options as well.

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!

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].

$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=]

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.