Updating to Drupal8.8.0 using Drush8.3.2 reports errors

[achourasia]

Describe the bug
When using Drush8.8.0 or Drush8.1.17 to update to Drupal 8.8.0 from Drupal 8.7.10 completes the updates, however it reports the following error.

This issue#3098814 has been discussed by Drupal core team, and they have decided to support it until 8.9.x.

To Reproduce
Install Drupal 8.7.10 then upgrade to Drupal 8.8.0
drush up -y

Expected behavior
Upgrade should be error free

Actual behavior
The following error was displayed after the upgrade
Error: Class [error] 'Drupal\Core\Controller\ArgumentResolver\RawParameterValueResolver' not found in Drupal\Component\DependencyInjection\Container->createService() (line 265 of /var/www/html/core/lib/Drupal/Component/DependencyInjection/Container.php) #0 /var/www/html/core/lib/Drupal/Component/DependencyInjection/Container.php(502): Drupal\Component\DependencyInjection\Container->createService(Array, 'private__Phticr...') #1
Workaround
Is there another way to do the desired action?
None, basically avoid drush8, Use browser based update or drush9 (which is not feasible for sites not build using composer)

System Configuration

Q	A
Drush version?	8.3.2 and 8.1.17
Drupal version?	8.7.10 upgrade to 8.8.0
PHP version	7.2.11
OS?	Debian 9.11

[greg-1-anderson]

Does the site work after displaying that error message?

If you run drush pm-updatecode followed by drush updatedb, do you still see that error?

[achourasia]

Yes, my site appears to run fine after this update, subsequent drush command show no errors. However in Drupal issue someone notes a problem in #11

[gitressa]

Thanks @greg-1-anderson to you and @weitzman for maintaining Global Drush 8.3 for Drupal 8, with all the drush dl and drush up --security-only goodness.

Is globally installed Drush 8.3 still in a "happens to work" state for Drupal 8.8 and Drupal 8.9, in the sense that it might stop working at any point? I see that there were a few hiccups with the recent upgrade to 8.8.0 mentioned in the Issue Summary: Class 'Drupal\Core\Controller\ArgumentResolver\RawParameterValueResolver' not found during update to 8.8.0.

I ask because I maintain a few Drupal 7 web sites of my own, and for NGOs and smaller businesses, and I am still on the fence: I really want to upgrade to Drupal 8, but the resources for a security team to be on stand by to test and roll out security updates via Composer on the evenings when they are potentially released is not there.

On the other hand, a cron triggered drush up --security-only -y has worked really well for many years now, since these are very un-customized, vanilla Drupal 7 builds, with copious back-ups, should anything go wrong, which ist hasn't.

So, I don't know if it would be possible to get a sort of tentative affirmative response to drush up --security-only working for Drupal 8.8 and Drupal 8.9, using Drush 8.3?

Within the next six to nine months I assume that the Automatic Updates module will be ready, which would essentially be the equivalent of drush up --security-only -y, only built into Drupal 8 core.

[gitressa]

I'll just add that the web site works fine after updating from 8.7.4 to 8.8.0, and that there are no lingering updates. From update.php page:

No pending updates.

Method
Ubuntu 18.04
Lando v3.0.0-rc.22 (PHP 7.2.24, Drush 8.2.3)

mkdir drutar8 && cd drutar8 && curl -sSL https://ftp.drupal.org/files/projects/drupal-8.7.4.tar.gz | tar -xz --strip-components=1
lando init --source cwd --recipe drupal8 --webroot . --name drutar8
lando start
drush site-install --db-url=mysql://drupal8:drupal8@database/drupal8 --account-pass=content -y
drush uli -l http://drutar8.lndo.site
drush up --security-only

[greg-1-anderson]

Yeah, Drush 8 support for Drupal 8.8+ is still best-effort only, and for Drupal 9 I would describe the current support as "happens to partially work".

Due to the way the pm-update code interacts with Composer autoloading, it is common for updates between some versions of Drupal to fail in the final steps of the upgrade. We won't necessarily fix problems if the resulting Drupal site still works after the error message is displayed.

Long term, the focus is on making autoupdates and Composer work better. We do not have a dedicated maintainer for the Drush 8 pm-* commands, so there will probably be continuing minor problems with Drush 8 and Drupal 8 / Drupal 9. It is hard to say how long support will continue; it is my hope that pm-* will continue to work for every Drupal 9 version, but whether it does or not is going to depend on what happens during Drupal 9 development (especially but not limited to the development period up to the initial 9.0.0 stable release). Drush 8 is unlikely to work with Drupal 10, though.

[gitressa]

Thanks for clarifying the Drush 8 status @greg-1-anderson. I am glad to see that it is still receiving updates, fx in #4408.

Is the state for Drush 8 with Drupal 9 still "happens to partially work", or perhaps closer to "happens to work" with this patch?

When the Automatic update module will be ready (hopefully not too far from now) it probably means that Composer has been more or less "abstracted away" from the user, and more optional than a requirement. Could it then be an option to add drush pm:download to Drush 10?

Would you consider PR's for the missing pm-* commands to Drush 10, or reject them, for example due to it programmatically taking too much effort to implement, or the opinion that we should use Composer from now on?

These two would be fantastic to get into Drush 10, for the reasons outlined in #4277 (comment):

- pm:download (dl)
- pm:updatecode (up)

Also, I was really glad to hear in the interview by Preston So from Tag1 in January 2020 that @weitzman is positive towards including Drush in core, I agree 100%. Drush is an indispensable tool for Drupal, which ought to be included by default:

• Drush 10 - Tag1 Team Talk #006
• Drush 10 & the Future of Drupal CLI

[weitzman]

Could it then be an option to add drush pm:download to Drush 10?

Sorry, thats not going to happen in Drush core. Anyone is welcome to write and maintain a contributed pm:download or pm:updatecode command.

[greg-1-anderson]

I don't know if it's useful or helpful to split hairs about which adjectives should or should not be inserted into the vague descriptive phrase "happens to work". The existing pm code partially implements the drupal.org changes to support core_compatible_version. The drush 8 bootstrap code mixes symfony 2 and symfony 4 classes, and this presently appears to work (although rationally, one would expect it shouldn't).

I don't know if we should hold out much hope for a global Drush 8 working with Drupal 9.1.

I don't think it's possible for a global Drush 10 to work with Drupal 9 and Drupal 8 at the same time (same installed vendor directory).

I would expect that Drush 11 will probably hard-break global installs of Drush, and require a site-local install with Composer.

I think that moving more cli commands into core is the only long-term viable way for non-Composer use of Drupal [*] to continue. It's hard to tell at the moment, though, whether Composer use might just become mandatory in Drupal core. Composer 2 is shaping up to be a lot faster & require a lot less memory. Right now it seems that adopting Composer would be the conservative site-builder's best option for planning for Drupal 9.1. That said, I too would be in favor of an initiative to increase the scope and capability of the cli commands in Drupal core.

[*] For those who use cli tools, anyway. Autoupdates + no cli is an option for some.

[gitressa]

Thanks for clarifying @greg-1-anderson, as always, in a very thorough way. I agree with your thoughts on Drush/CLI in core:

That said, I too would be in favor of an initiative to increase the scope and capability of the cli commands in Drupal core.

I was just alerted by @rfay in Provide a core cli tool for the most common features of drush that there will be a key discussion at Drupalcon, A robust command line tool for all Drupal sites, which I am looking forward to. I will keep my fingers crossed that Drush will one day be baked into Drupal.