Add Composer support directly to Provision.

I'm reluctant to get this in as-is given that:

• The code here continues the tradition of functional programming making it harder to read, maintain, and enhance. Aegir Composer, as it's currently written, is very clean OO, making it a pleasure to work with.
• Aegir Composer introduces the concept of deployment strategies, which cleans up the platform creation UX.
• I'm a fan of the small-core philosophy, where we make plug-ins modular, and slurp them in as opposed to placing everything in the base modules.

But given that

• the Aegir 3 code is throw-away in the long term, and
• keeping Aegir core small is just one philosophy,

...I won't block this if everyone's on board. However, if it goes in, we should must reincarnate Aegir Composer as Aegir Deploy (hosting_deploy) so as not to lose the deployment strategies or the clean-up of the Create Platform page. I actually merged all of the well-written documentation for this stuff earlier today. (It would need a bit of tweaking, but not a huge deal.) See #2931158: Add documentation to Aegir Docs for details.

It's worth noting that hosting_composer also provides an option to build platforms with composer create project

What about the '--no-dev' parameter for composer. One of my D8 test platforms (installed with drush dl) has a composer.lock file but was changed by the updated verify task by downloading things like phpunit.

How to handle servers that don't have composer installed? The first error line in a task log might be obvious for us, but it would not be nice to confront our users with that after the next aegir release. Should we start installing it via debian/aegir3-provision.postinst and not it in the release notes?

Re. "small-core", here's a good description. The most relevant definition is:

The real historical problem that has made the decision to add or remove components in [Aegir] core difficult is the dichotomy between [Aegir] as a framework and [Aegir] as a product. Framework advocates want a small, agile core focused on robust APIs that can advance at a faster pace. We’ve traditionally called this “small core.” Product advocates are focused on [Aegir] being a complete product for website building; with sensible defaults, out-of-the-box [website management] tools, and a plethora of features.

This was the fundamental idea behind the "golden contrib" initiative.

FWIW, I think adding Drush Make directly to core was a mistake; specifically because it is now becoming irrelevant, and we can't clean turn it off.

This feature is so badly needed, that I'm eager to support whatever hack in Aegir core is needed to make it happen. *Now*.

Let's leave code elegance and related subtleties for another occasion (and branch) once we will have more time to do these things accordingly to the rules of the programming art.

That is my opinion/vote, at least.

GTD!

Last week I started coding a bit in the Debian postinst scripts to install composer. However now that it's included in both stretch and xenial it seems better to just defer to those packages.

Unfortunately it's not in Jessie, so adding it to 'requires' would break there. ... something we can do in 4.x but as Jessie is supported until 2020 breaking it in 3.x now is not nice.

2937147-composer-install now has a commit I'm testing for this

Seems to work ok... I just added a shell_exec('which composer') to be sure we're not failing when an existing installation just lacks the composer binary.

I created #2938992: Enhance composer support in Aegir core to handle the new option in hosting_composer.

Great ... https://gitlab.com/aegir/provision/pipelines/16791163 is running a final test ... lets merge if that passes.

For follow-up work necessary to provide the Deployment Strategies functionality, see #2938992: Enhance composer support in Aegir core.

Wow, having followed #2736801 and now this issue, I am so delighted to see this! BIG THANKS Jon and everyone else!!!

I agree, this is a big deal. Thanks to all who worked on this!