[META] Move provision off of Drush

This might move fast. See 4.x branch. See https://packagist.org/packages/aegir/provision

Turns out DrupalConsole already has a lot of stuff we might want to use, like a DrupalFinder class. I got a skeleton Provision CLI working in that branch.

- If you want to build our own console worker we should look into http://robo.li/framework/. The task runner that Drush 9 is build around. An extension of Symfony Console.

100% YES to using Robo. I love it. I have already started a bunch of Robofiles and have looked into using it as a Framework for Terra: https://github.com/terra-ops/terra-cli/pull/130

However for this first phase, I think we should just use console components directly. Adding Robo adds a layer of abstraction we don't need right now, when we need to focus on drush command to symfony command conversion. To use Robo properly we will have to do a lot of thinking and testing.

As for drush support: I think within Aegir for Drupal <8, we can still install drush globally for those sites. The new Provision CLI can easily kick off to global or local drush (or other scripts).

Thanks for talking to him!

This morning I made good progress creating a "SaveCommand" class that will map to provision-save.

I think to start, in this new ProvisionCLI, we can pass off to the drush commands until all functionality exists in the new classes.

That way, we keep the system working as we go along.

See https://github.com/aegir-project/provision/blob/4.x/src/Command/SaveComm... for the first Aegir\Provision\Command class.

See branch 2912579-provision-cli in hosting module for changes that switch from provision_backend_invoke() to new Process().

Update:

1. Added CLI configuration loading from ~/.provision.yml. Defines aegir_root, config_path, script_user. Defaults to your local system, detected user and home dir. Used ConfigurationInterface to enforce YML configuration
2. Added Aegir\Provision\Context classes for Site, Server, and Platform. Used Symfony ConfigurationInterface for these, allowing us to define strict configuration for each type. Each contain method option_documentation() that is passed to the "save" command.
3. Added Initial "save" command. Takes options and saves them to a YML file for each context.
4. Added "status" command. Outputs CLI configuration and list of contexts, also add context name as argument to see info on that context.

Screenshots!

To give you an idea of how awesome Symfony will be in rebuilding our Context classes, see ServerContext.php:

namespace Aegir\Provision\Context;

use Aegir\Provision\Context;
use Symfony\Component\Config\Definition\Builder\TreeBuilder;
use Symfony\Component\Config\Definition\ConfigurationInterface;

<?php

/**
 * Class ServerContext
 *
 * @package Aegir\Provision\Context
 *
 * @see \Provision_Context_server
 */
class ServerContext extends Context implements ConfigurationInterface
{
    /**
     * @var string
     * 'server', 'platform', or 'site'.
     */
    public $type = 'server';
    
    static function option_documentation()
    {
        $options = [
          'remote_host' => 'server: host name; default localhost',
          'script_user' => 'server: OS user name; default current user',
          'aegir_root' => 'server: Aegir root; default '.getenv('HOME'),
          'master_url' => 'server: Hostmaster URL',
        ];

        return $options;
    }
    
    /**
     * {@inheritdoc}
     */
    public function getConfigTreeBuilder()
    {
        $tree_builder = new TreeBuilder();
        $root_node = $tree_builder->root('server');
        $root_node
            ->children()
                ->scalarNode('name')
                    ->defaultValue($this->name)
                ->end()
                ->scalarNode('remote_host')
                    ->defaultValue($this->properties['remote_host'])
                ->end()
                ->scalarNode('script_user')
                    ->defaultValue($this->properties['script_user'])
                ->end()
                ->scalarNode('aegir_root')
                    ->defaultValue($this->properties['aegir_root'])
                ->end()
                ->scalarNode('master_url')
                    ->defaultValue($this->properties['master_url'])
                ->end()
            ->end();
        
        return $tree_builder;
    }
    
}

TreeBuilder is what all of symfony uses for defining configuration. See https://symfony.com/doc/current/components/config/definition.html

Well clearly that was needlessly hard coded!

With a little work, we are now loading Config for Contexts automatically from Context::option_documentation*()!

Since I got that working, I went ahead and made provision save command fully interactive, based on the same method: Context::option_documentation()

Awesomesauce. Now we just have to fill out Service classes and figure out how to let them add properties to $TYPEContext::option_documentation and we're halfway there.