Aegir 3 is incompatible with Drush 9+

Having the same problem here :

aegir@server:~/platforms$ drush @platform_drupal8.5 provision-verify  -vvv
Include /var/aegir/hostmaster-7.x-3.145/profiles/hostmaster/modules/aegir/hosting_logs/drush [notice]
Include /var/aegir/hostmaster-7.x-3.145/profiles/hostmaster/modules/aegir/hosting_git/drush [notice]
Include /var/aegir/hostmaster-7.x-3.145/profiles/hostmaster/modules/aegir/hosting_git/pull/drush [notice]
Include /var/aegir/hostmaster-7.x-3.145/profiles/hostmaster/modules/aegir/hosting_git/checkout/drush [notice]
Include /var/aegir/hostmaster-7.x-3.145/profiles/hostmaster/modules/aegir/hosting_remote_import/drush [notice]
Include /var/aegir/hostmaster-7.x-3.145/profiles/hostmaster/modules/aegir/hosting_tasks_extra/hosting_sync/drush [notice]
Include /var/aegir/hostmaster-7.x-3.145/profiles/hostmaster/modules/aegir/hosting_tasks_extra/drush [notice]
Loaded alias @platform_drupal8.5 from file /var/aegir/.drush/platform_drupal8.5.alias.drushrc.php [notice]
Loaded alias @server_master from file /var/aegir/.drush/server_master.alias.drushrc.php [notice]
Loading nginx driver for the http service [notice]
Running command composer install --no-interaction --no-progress --no-dev [ok]
Executing: composer install --no-interaction --no-progress --no-dev
> DrupalProject\composer\ScriptHandler::checkComposerVersion [success]
Loading composer repositories with package information
Installing dependencies from lock file
Package operations: 1 install, 0 updates, 0 removals
  - Installing drush/drush (9.2.1): Loading from cache
Generating autoload files
> DrupalProject\composer\ScriptHandler::createRequiredFiles
Command ran successfully in 1s: composer install --no-interaction --no-progress --no-dev [success]
Drupal sites directory /var/aegir/platforms/umoncton-staging-31371/web/sites is writable by the provisioning script [success]
This platform is running drupal 8.5.0 [notice]
Undefined index: version provision_drupal.drush.inc:598 [notice]
access_test.info.yml not found.
Found install profile Configuration installer [notice]
Found install profile Standard [notice]
Found install profile Minimal [notice]
Found install profile Configuration installer [notice]
Platforms path /var/aegir/platforms exists. [success]
Platforms ownership of /var/aegir/platforms has been changed to aegir. [success]
Platforms permissions of /var/aegir/platforms have been changed to 755. [success]
Platforms path /var/aegir/platforms is writable. [success]
env COLUMNS=179  /usr/local/bin/drush  --backend=2 --verbose @platform_drupal8.5 provision-save 2>&1 [notice]
 [preflight] The alias @platform_drupal8.5 could not be found.
The command could not be executed successfully (returned:  [preflight] The alias @platform_drupal8.5 could not be found. [error]
, code: 0)
nginx has no platform config file [notice]
Executing: sudo /etc/init.d/nginx reload
nginx on server has been restarted [notice]
Command dispatch complete [notice]
aegir@server:~/platforms

We have installed Drush 8 instead of Drush 9 and we still get the same issue.

The command could not be executed successfully (returned: [preflight] The alias @platform_name could not be found. [error]

To verify the aliases, I type de following commands:

$ cd /var/aegir/hostmaster-7.x-3.145/
$ drush st
…
…
Drush version 8.1.16
…
…
$ drush sa
@none
@self
staging.example.local

Can the drush alias staging.example.local miss the @ symbol?

Actually, changing Drush to use version 8.1.16 allows to build the Drupal 8 platform. But we get the previous issue when trying to create a site.

Has their been any movement on this?

We are at a stand-still with our d8 deployments utilizing Aegir because of this....

Downgrading priority as you can simply remove the site-local Drush from your platform.

If you still want to use composer create-project, you can, but you need to ensure it's being sourced from somewhere that doesn't depend on Drush as part of the build (i.e. included in composer.json). So instead of using the Composer deployment strategy with Aegir Deploy (where it sounds like the official package repository depends on it), use Composer (from source), where you would specify a Git repository with a composer.json that doesn't include it.

Said another way, you could fork the official composer.json, which you're probably doing anyway, and remove the dependency.

Jon, can you clarify what command or file should be changed to achieve this workaround for Drupal 8.5.X sites with composer and drush9?

I tried settings variable in .env with "DRUSH_FINDER_SCRIPT=1" line and just setting on bash with aegir user "export DRUSH_FINDER_SCRIPT=1". It seems that the problem wasn't solved for me. Or maby I'm settings environment variable not properly.

So, would be nice to have some sort of guidance on how this actually can be used right now. Thanks for your awesome work! Love the presentations on DrupalCamp Montreal!

Basic drush provision-save does not work because drush hosting-task set's the --root option, which forces drush to switch to site local.

So adding --root overrides the launcher/finder results? Have you found where in the Drush codebase that's happening?

After requiring Drush 8.x instead of 9.x in my repo composer.json, I'm using the following workaround:

SSH into the (Devshop) Aegir server as the 'aegir' user, cd into the appropriate platform directory, run "composer update --no-dev", and then from the (Devshop) Aegir interface, run a Git Pull task for the appropriate platform, then Verify Platform task, and all is well.

I hope this helps anyone who may be in a pinch because of this conflict :)

EDIT: fixed the typo in the composer update command, and removed a redundant step 🤦

It should be noted that running "composer update" in production is a terrible idea, and you should only do this if you're absolutely positive it won't break anything. Test this on a dev environment first, and be sure all of your required/desired package versions are specified in your composer.json.

We've had good luck working around this by moving drush/drush to the require-dev section in composer.json. It works because core runs composer with --no-dev, so drush doesn't get included in the build.

I added better in-line documentation to the Create Platform form in the latest release of Aegir Deploy, which explains the workaround:

Deploy a Composer project from a Packagist repository

You may deploy this platform from a Composer package hosted on Packagist, the PHP package repository.

To provision a clean Drupal 8+ core codebase, one would typically enter web for the Docroot, drupal-composer/drupal-project for the Composer Package Name, and 8.x-dev for the Composer Package Version. For more information on that project, see the project page on Packagist.

However, you will most likely want to customize your installation by starting with this project as template, and then adding contributed and custom modules and themes. To do that, use the Deploy a Composer project from a Git repository option instead, which allows you to clone from your own Git repository instead.

It should be noted that this option is not currently working due to Including Drush 9 in a Composer-based platform breaks Provision's Verify. Use the Deploy a Composer project from a Git repository option as a workaround until the issue is resolved.

Deploy a Composer project from a Git repository

You may deploy this platform from a Composer project Git URL.

You'll need a Git repository started with something like the following:

composer create-project drupal-composer/drupal-project:8.x-dev new-drupal-project --stability dev --no-interaction

Note that until Including Drush 9 in a Composer-based platform breaks Provision's verify is resolved, the Drush dependency must be moved to the development section of the makefile in order for the build to work properly within Aegir. So you'll need to either move it from the require section to the require-dev section manually, or run a command like this:

composer require --dev 'drush/drush:^9.0.0'

That's a bit harsh. We can simply update the documentation to state that drush/drush needs to be moved to require-dev (which works perfectly fine), and then mark this as fixed.

Side note:

On ACSF we had 3 versions of Drush available to deal with any number of dependency issues.
- drush6 envoked drush v6 (ACSF was Drupal 6)
- drush7 envoked drush v7
- drush8 envoked drush v8
- drush envoked drush v9 respectively

My thoughts are that we could move default Drush to v9, and any Drush version specific command that need to run a older version can by being explicit (eg. drush8 --whatever). Which helps support the current need for Drupal8 sites and helps usher along a migration path that is sustainable to maintain.

The only solution is to make Provision a true standalone CLI with it's own libraries and a clean separation from itself and it's applications.

Not exactly. We've been talking about updating Drush 8 so that it can stop handing off control to a local Drush if a variable is set. This shouldn't be too much of a problem to fix upstream, given that @ergonlogic is already a Drush maintainer (pending a discussion with the other maintainers).

We started working on this internally, but then priorities shifted, and we haven't got back to it yet.

@Jon Pugh: So it sounds like you're not actively working on fixing this in the 3.x branch? As such, I've unassigned you. Please re-assign this to yourself if I'm mistaken.

In any case, the issue summary needs to be updated with all of the comments we've got here:
* Possible solutions, and
* Workarounds.

We have fixed this in BOA by removing Drush 9 from the codebase automatically on the first verify of the platform, when Drush 9 presence doesn't break anything, because Drupal is not bootstrapped yet, because no site is installed yet. We have added the cleanup code both in Provision and the bash scripts Provision uses to fix permissions and ownership. The problem is gone now.

That's yet another good workaround then. :)

This issue is really starting to make this platform a non-starter for Drupal 8 sites.

We can no longer run the following:
- custom migrate API modules
- config_update
- search_api

All of which are critical to running contemporary multisite platforms.

I recommend making Drush 9 the default `drush` and any deprecated need of Drush to run be explicitly called using `drush8`.

Just updated the IS with a problem description, solutions and workarounds.

Note that funding would help make this problem go away sooner.

Better title.

I should add that while BOA removes site local Drush 9 to prevent conflicts with Drush 8 which is used in Aegir backend, BOA also adds system-wide Drush 9, and even automatically converts all Drush aliases to make them compatible with Drush 9 (and soon Drush 10), so you can still use `drush9 @sitealias task` or `drush8 @sitealias task` on command line and you will not be affect by Aegir compatibility with Drush.

It's also important to note that switching to Drush9 would be pointless, because it would remove support for hosting Drupal 7 and Drupal 6 LTS sites, including Aegir own control panel..

Please update the IS with that new info. :)

I would like to tangentially like to point out that Drush 8 is now 8.3.2 and Aegir's default Drush install is 8.1.2.
Manually upgrading to Drush 8.3.2 seemed to solve some of our issues.

In regards @memtkmcc 's comment, I was working on the misinformed premise that Drupal 7 worked with Drush 9, and now I can see that it is not via the compatibility grid here: https://docs.drush.org/en/8.x/install/

That being said, having multiple Drush version support via the default install of Aegir would be ideal, sans the extra management and potential new user confusion.

Just improved the issue description.

Is this still supposed to be the case with the current recommended git-rep For Drupal 8.8.1?

I installed Drupal 8.8.1 with AEGIR using the composer-method.

Deployment strategy: Deploy a Composer project from a Git repository
Docroot: web
GIT URL: https://github.com/drupal/recommended-project.git
Branch/tag: 8.8.1

On the "add platform" page there is an advice to add DRUSH do require-dev.

If I ignore this advice, everything is fine. If I issue the composer command to put DRUSH into require-dev - than I get the problem of incompatibility. I was able to resolve this by removing Drush.

I certainly haven't tried it with the new official project repos (they didn't exist when those docs were written) so thanks for the report. Let's wait for some others to confirm.

The recommended project installed from git repository works for me too. These two options worked:

1) Create platform with drupal/recommended-project:
Deployment strategy: Deploy a Composer project from a Git repository
Docroot: web
GIT URL: https://github.com/drupal/recommended-project.git
Branch/tag: 8.8.2

2) Create platform with aegir/drupal-project-composer:
Deployment strategy: Deploy a Composer project from a Git repository
Docroot: web
GIT URL: https://gitlab.com/aegir/drupal-project-composer
Branch/tag: aegir3-8.x

In both cases:
- the platform is operational and sites can be created from it
- the platform "breaks" as expected (verify fails) as soon as I add a module that requires and loads Drush 9 (eg after a "$ composer require drupal/gdpr:^2.0")

Some collateral observations from the test (which may warrant the creation of separate tickets?):

• as at today (2020-02-12) aegir/drupal-project-composer using branch aegir3-8.x builds a platform with Drupal core 8.8.1 rather than 8.8.2, released 11 days ago. I thought it was automatically updated and using the latest drupal core. Doing the same on 2019-12-20 built a platform using 8.8.1, released two days earlier.
• on a Virtualbox VM with 2Gb RAM and 4 CPU, the platform is consistently built/verified in about 15 seconds for the drupal/recommended-project but in about 3 minutes 15 seconds (13 times longer) for the aegir/drupal-project-composer !?
• these times are essentially the same if I first clone the git repositories locally and build the platform from the local git

Thanks @agaq from comment #50 1) Create platform with drupal/recommended-project works for drupal 8.9.0

This is what I did: Create the drupal recommended project using composer

cd /var/aegir/platforms/
composer create-project drupal/recommended-project:8.9.0 drupal-8

And after that I could enter the information as explained in the comment #50 from the aegir UI (using Branch/tag: 8.9.0). No errors shown creating sites nor creating platforms. No more tests have I done to date.

This also means that Aegir cannot be used with Drupal 9 as Drush 9 and above is required.

Aegir fully supports Drupal 9 with recent patches I have submitted to head. We don't need Drush 9 for anything, perhaps apart from running Drush commands provided by D9 contrib on command line, because then Drush 9 needs different aliases, but they are easy to generate.

#3150004: BOA backport Drupal 9 support

What does this mean in practical terms - that an updated version (eg a debian package 3.188) incorporating these recent patches will be released in the near future, and that it will then be possible to install Drupal 9 using the git repository https://gitlab.com/aegir/drupal-project-composer using a branch/tag "9.0"?

https://docs.drush.org/en/master/install/#drupal-compatibility indicates that Drupal 9 requires Drush 10, not Drush 9.

@agaq -- BOA (our hosting stack at omega8.cc, which includes Aegir HEAD) is running on Drush 8 for Aegir backend, plus drush8 and drush9 on command line to support Drupal 6, 7 and 8 also on command line. We haven't tested the differences on command line yet, but will include drush10 too, if that's actually necessary. The official Drupal compatibility chart published by Drush is not really what the actual Drush versions compatibility is, because even Drush 8 is still patched for Drupal 9 minimal compatibility to allow transitions between versions supported. That's also why Aegir can run on latest Drush 8 head and be able to fully support Drupal 9 sites installation, cloning, migration etc. There can be still some fine details to iron out, but it just works on BOA with all recent patches included. They should be a part of next Aegir release, hopefully.

Am I correct in understanding Aegir 3.x does not support Drupal 9 sites, and we need to wait for 4.x or 5.x?

Update: We were able to install a Drupal 9 site on Aegir 3.192 after upgrading Drush to 8.4.6.

Same here. But you can not have Drush installed the the vendor folder of Drupal 9. But without that it works.

Playing around of having drush10 installed outside the Drupal 9 folder. Kind of works, but there are some minor bugs but there is work around for them.

@kristofferwiklund if you have any notes or tips I'd love to see them. We're running into the same issue at the moment.

I have one more workaround for the pile... we're building a project that lists Drush 10 as a direct (not dev) dependency, so we're not able to move it to "require-dev". I've been successful in aliasing our project drush back to 8 and then deploying to Aegir without conflict.

composer require drush/drush:"8.4.6 as 10.3.6" --update-with-all-dependencies

D9 sites will... not be super happy with this, but it should be an option as long as you're not trying to do much fancy with drush in your Aegir environment.

Kindly add that to the list in the IS? :)

It took me some time to confirm my method (which was informed by a lot of this thread, so thanks all).

This setup allows you run Drupal 8 and Drupal 9 platforms on the same Aegir server, while not breaking Aegir's functionality:

- We first need to disable cloaking as per this post. Either do that per-site by adding $options['provision_db_cloaking'] = FALSE; to drushrc.php and then re-verifying, or globally using the code from these PRs.

- We have packages that list Drush 10 as a dependency so we need to override it. This can either be done in the base composer.json OR somewhere in your deploy pipeline. Drush 10 has a lot of dependency tentacles that don't like it going away, so the other packages are required in order to keep those from getting unhappy.

composer require drush/drush:"8.4.6 as 10.3.6" vlucas/phpdotenv:"^5.3" consolidation/robo:"^1.1.5" --update-with-all-dependencies --update-no-dev --no-scripts

- Now we have a platform-local Drush 8.4.6... and since it's still Drush 8, the Aegir aliases still work! But... we do need to either call drush directly or alias it:

# The hard way 
/var/aegir/platforms/my_platform/vendor/drush/drush/drush --root=/var/aegir/platforms/my_platform/docroot --uri=my.site.com cr
# The easy way
/var/aegir/platforms/my_platform/vendor/drush/drush/drush @my.site.com cr

I still cannot install Drupal 9 based sites using Aegir.

Any pointers

What error do you get?

Comment #63 and #65 were the base we used to achieve the solution.

The steps which we followed to get the site up and running on Aegir are below.

1. Created a platform with Drupal 9.2 using composer but didn't added any information about drush in composer.json file.
2. Added new platform in Aegir and Verified the platform. We used composer based option in creation of platform.
3. Added composer require drush/drush:"8.4.6 as 10.3.6" in the platform created repository and pushed the changes.
4. On web server pulled the new changes i.e. drush inclusion in composer file.
5. Added new site using this platform.
6. Verify site.

Thanks Colan this worked very well for provisioning a site.
For anyone trying to migrate into a site provisioned using drush8, you'll want these older versions of the migrate modules:

    "drupal/migrate_tools": "^4.5",
    "drupal/migrate_plus": "^3",
    "drupal/migrate_upgrade": "^5",

Anybody by chance have Aegir 3 working with Drupal 10? We were able to get Drupal 9, but I've tried to apply some of the above solutions to Drupal 10 and not having any luck. Never mind, I see the Drupal 10 issue now :( #3353492: Drupal 10 support for Aegir 3

TL;DR BOA supports Drupal 10 while running slightly modified Drush 8. We don’t need newer Drush versions and we shouldn’t.

Longer version follows.

Aegir 3 can work only with Drush 8 because it’s the only still supported Drush version which can be reliably used as standalone Drush.

All post-8 Drush versions up to 11 could theoretically be used as standalone (on command line but not with Aegir) if their dependencies matched the managed Drupal site code, which in practice happens rarely and thus should be used as site-local only.

Composer doesn’t care about possible versions conflicts between Drush and Drupal and you could get pretty different versions of the same Drush release installed depending on when you have installed it. This makes using them as standalone a completely unpredictable mess.

That’s why Drush 12 has been officially announced as the first version which can’t be used as standalone at all — no matter how hard you would try.

The only question was therefore: can we make the old good Drush 8 able to avoid conflicts despite aggressive deprecation coming with Drupal 10?

It seemed impossible initially, so we at Omega8.cc launched a complete rewrite of our BOA stack to make it use Aegir 3 without Drush — at least without the way it was always used, based on bootstrapping Drupal directly, with the intention to use it as a bridge with our own backend code, not affected by any Drush and Drupal compatibility issues.

It turned into serious rabbit hole and we have realized we couldn’t make it a mature enough project before Drupal 9 EOL, which in turn got us back in the dirty hacking and trying to make things work, removing obstacles as we go through tedious and frustrating debugging and testing cycles.

We didn’t believe it was possible, really, but we just wanted to give it a try before taking the risk of switching horses completely and without option to go back.

Guess what.. it worked! We are planning to release it tonight and upgrade all hosted Aegir systems later this night. More details are coming once we have more free time.

Take a look: https://github.com/omega8cc/boa/issues/1678#issuecomment-1778803057

Hey @memtkmcc glad you got it figured out! Would you mind sharing what would work for those of us not on the BOA stack? I tried installing the BOA drush 8 fork and using your D10 patch posted on your github, but I must be missing something still as my site install task still contains errors. Are you installing drush 11/12 on the site level? Any help or direction would be greatly appreciated. Thanks for all your efforts!

Hey @porchlight, we are currently preparing to backport our patches to all relevant parts of Aegir and will also post a how-to to list requirements and changes normally automated in BOA but requiring some simple manual work for standalone Aegir. New issues will be opened to track this process.

@memtkmcc AMAZING! Looking forward to it! Thanks for the quick reply

Trying to use your composer file @jon-pugh
"The `url` supplied for the path (../../../devmaster) repository does not exist"