Unite with hosting_git?

The main goal was to have a minimalist, safe git-based platform deployment mechanism. hosting_git provides various tasks such as 'pull' and 'checkout' that, while useful in a development scenario, are dangerous for a production multi-site deployment.

OOP was another reason, though. It should also simplify #2871776: Support altering the 'git' command in support of #2868517: Support private git repos.

I strongly believe we should put support for git and composer directly in Aegir core. It's just as relevant as drush make based platforms at this point. Having written a ton of hosting_git, and a ton of devshop, I can tell you that treating git and composer would be MUCH easier and much less code if it were in core Aegir.

As a way forward with this module and Aegir Distributions, does this make sense as a plan?

1. Stabilize this stuff.
2. Add any missing features from hosting_git.
3. For hosting_git features that are "dangerous", let's add warnings to the UI.
4. Add this subsystem to the Golden list.
5. Remove hosting_git from the Golden list.

@Jon Pugh: Placing things in the Golden list (instead of Aegir core) keeps us in line with the microkernel philosophy. We would be able to swap out separate components and replace them on their own, without having to deal with a huge monolithic Aegir. This make upgrades like AegirNG much easier to divide and conquer.

@ergonlogic: Given your response above, can we assume that you no longer have faith in a solution that uses your patch at https://www.drupal.org/node/2736801#comment-12034550, given that it's for hosting_git? If this is in fact the case, we should state that in the issue over there.

This now bundles a platform_git module that seems to have overlap with hosting_git.

Was the desire for OO code the reason for this?

OOP is certainly preferable. It makes for much cleaner code, and may allow some of it to more easily be ported to Drupal 8 down the road. But that's not the main reason for creating platform_git.

The main reasons are illustrated best by the inline documentation from platform_git:

Deploy from Git
You may deploy this platform from a Git repository. This strategy is appropriate for hosting scenarios where multiple sites will share common platforms. It differs from Manage with Git in that, once deployed, platforms are treated as immutable.

... and hosting_deploy:

Manage with Git
You may deploy and manage this platform from a Git repository. This strategy is appropriate for development scenarios or when each such platform will only host a single site. It differs from Deploy from Git repository in that, once deployed, platforms can be updated or otherwise changed via Git.

So, hosting_git and hosting_platform_git really satisfy different use-cases. In my opinion, trying to shoe-horn the two into a single implementation has been counter-productive.

Additional functionality is also distinct from anything to do with git, as illustrated in the "distro" branch of the docs (which is awaiting a merge, btw):

Composer deployment
In order to host Drupal 8 distributions, a new deployment option was added that builds a platform from a Composer package. It takes a template project name (and optional version) which it then provides to Composer's `create-project` command.

Composer install
While not specific to the `create-project` mechanism, Aegir will now scan for a `composer.lock` file, and run `composer install`, in order to install a platforms dependencies.

I strongly believe we should put support for git and composer directly in Aegir core. It's just as relevant as drush make based platforms at this point. Having written a ton of hosting_git, and a ton of devshop, I can tell you that treating git and composer would be MUCH easier and much less code if it were in core Aegir.

I get where you're coming from, but when we make a sub-system pluggable, the trade-off is that there'll be more required boilerplate.

In retrospect, I think including Drush Make in platforms directly was a mistake, and part of the reason it can be hard to alter platform deployment behaviour. Had we, instead, recognized that platform deployment should itself be a pluggable sub-system, I think we could have provided a framework to minimize the boilerplate (and complexity) of adding new deployment mechanisms.

I've tried to begin addressing this with the hosting_deploy module (a sub-module of hosting_composer) to clean up the front-end, at least. Future iterations (or versions) should go further and address the back-end too.

As a way forward with this module and Aegir Distributions, does this make sense as a plan?

1. Stabilize this stuff.
2. Add any missing features from hosting_git.
3. For hosting_git features that are "dangerous", let's add warnings to the UI.
4. Add this subsystem to the Golden list.
5. Remove hosting_git from the Golden list.

As I stated earlier, hosting_platform_git is really meant to exist alongside hosting_git, so (2) and (5) aren't needed. (3) should really be discussed in the hosting_git issue queue, imo.

So, that leaves stabilize this module and then add it to Golden Contrib, which I strongly support. I think the next step is to get some broader testing, so let's release a beta and follow-up in #2876247: [meta] 3.0 release of Aegir Composer.

Oh, and in case it wasn't obvious, I think the approach in this module is preferable to the patch in #2736801: Support Composer for platform builds. I'll update that issue too.