deployfrompackegist error

1. Composer is pulled in with the default Debian installation, and is also a requirement for the manual installation method. So I don't believe there's anything else to do here.
2. php-mbstring gets pulled in with Composer (in Bionic at least). More specifically, composer requires php-symfony-console, which requires php-symfony-polyfill-mbstring, which requires php-mbstring. Again, nothing to do here.
3. We could not find an applicable site for that command: This is a duplicate of #2997545: Cannot install Drupal 8 platform, which was fixed with a documentation workaround.
4. I've always needed php-curl for Aegir even before I used this module. Maybe we should make it a requirement for Aegir core in a separate issue?
5. 512 in a vagrant box is no longer sufficient: Sounds like a core documentation issue not relevant to this one. Can we just add this to the regular docs?
6. Alias not saving: This sounds like the only real issue to work on here. I've highlighted it in the IS.

Can you provide more logs?

What Packagist project are you trying to install?

Nevermind, I see that it's drupal-composer/drupal-project

Installing drush/drush (9.5.2): Loading from cache

I suspect this is at least half the problem. As noted, I think this is documented in #2997545: Cannot install Drupal 8 platform.

While I haven't tested this recently, I previously had success with burdamagazinorg/thunder-project and goalgorilla/social_template.

If Packagist deployments work with Thunder or Open Social, then the underlying mechanism should be valid. In fact, the platform build with composer create-project does appear to work as expected. So it's just not creating a valid platform, as far as Aegir is concerned. So, if we build the platform manually, and choose the "none" deploy strategy it should fail in the same way.

I'll try to make some time to test the Packagist deploy with one of the distros that should work.

We could perhaps try validating that Drush isn't in require, and throw an explicit error if it is. I don't know if Composer supports that directly, or whether we'd need to load the composer.json (or composer.lock?) and check directly.

A couple notes from testing this:

1. goalgorilla/social_template required PHP 7.2+, so it fails on my local test VM which is at 7.0
2. Failed platform builds don't clean up properly, so we probably need a roll-back hook.
3. `composer create-project` appears to re-calculate dependencies (like `composer update`) , which is very memory intensive. Even on a VM with 2GB of RAM and `memory_limit = -1` for PHP CLI, this process runs out of memory for me.
4. We should consider adding `--no-dev` here as well.

Re. #3, bumping up the RAM to 4GB allowed it to progress past the dependency re-calculation. Unfortunately, Drush 9 is in `require` here, so it fails for that reason.

I pushed fixes for #2 and #4.

It still fails to build a useable platform, but that's because of the presence of Drush 9.

Maybe we should just remove this module until we've found a proper fix for #2953349: Aegir 3 is incompatible with Drush 9+.

But couldn't one still use it with a Packagist repository that doesn't include Drush 9? This is what I was alluding to in the in-line docs. You could fork one of the standard ones, move Drush to require-dev, and publish it as a new repo (e.g. drupal-project-drush-in-dev)?

As discussed with @helmo, this is exactly what I'm doing. Once it's active, I'll update the help text to point to this new one instead. Repository is located at https://gitlab.com/aegir/drupal-project-composer, and the default branch is aegir3-8.x (instead of 8.x).

I'm now waiting for @Jon Pugh to grant me access to the aegir group on Packagist.org so that I can make the package available at aegir/drupal-project-composer.

Will also need to enable auto-package updates from the Git repo. See https://packagist.org/about#how-to-update-packages for details.

The above is now done, except that Packagist is forcing us to use dev-aegir3-8.x. Still testing...

This is working now that we removed the remaining Drush remnants from the repo.

I'll update the example with the new source info, and clean up the help text.

@helmo et al.: Please test the dev branch now. If it's all good, I'll cut a new release.

Make sure to clean your Composer cache first. Otherwise, you'll be pulling in the old code.

I've tested this; it does work, but requires at least 4G of RAM, so I've updated the inline documentation with the attached patch. See also this commit on aegir_objects--it was failing silently before.

Thanks for figuring out the problem there, and adding the help text which highlights it.

1. However, I'm not crazy about the UX though. A DRUSH_NO_SITE error doesn't naturally translate into something like Memory exceeded: Rerun this task after increasing your RAM.

Assuming that it's too difficult to detect that this is happening, could we at least add something like this to the new help text, along with what you just added?

If you see a DRUSH_NO_SITE error in the logs, it most likely means that you've exceeded all of your available memory. Try rerunning the task after you've made more available.

2. Let's also add this stuff to the module's README?

Apologies if I wasn't clear; with this commit in aegir_objects, the real error will no longer be suppressed; you will now see the out of memory error in the log, and the deployment will stop before it gets to the condition that triggered DRUSH_NO_SITE.

The DRUSH_NO_SITE error was happening because the out of memory error was being silently suppressed, but then the platform was being deleted as part of post-failure cleanup.

2. Let's also add this stuff to the module's README?

Since the errors are all legit, I think all that's left is to add the docs changes from the patch to the project's readme.

Pushed docs fixes.