It's been a long couple of weeks...
... long...
So I'll try and keep it brief. Time to start testing the water for a Drupal 9 upgrade. Step 1 -- let's not muddy the water in my Drupal 8 workflow; much better to get a VM up and running, branch out, and keep my local machine safe and sound in the meantime. As an added bonus, I can do a Ubuntu installation and run it from my Xubuntu host: nice opportunity to look at the two OS'es side by side (diagnosis so far: Xubuntu for the win). Take note: Ubuntu 18 comes preloaded with a global installation of PHP7.2
Fastest way to get a LAMP stack up and running on Linux (that I know of) is with XAMPP. Drupal 9 requires PHP7.3 or later, but since XAMPP can be downloaded with it's own version of PHP, it shouldn't matter that the global installation of PHP on the OS is 7.2... or... should it?
Quick note: the global installation of PHP on Ubuntu is found at /usr/local/bin/php (if in doubt, verify your global PHP location with $which php); the local installation of PHP for XAMPP is found at /opt/lampp/bin/php
Getting Composer to Play Nice with XAMPP
In an attempt at transparency: I'm a drush kind of guy. I resent Drupal for increasingly moving the maintenance of sites into Composer. If you ask me, the removal of pm-updatestatus from Drush 10 is a crime against humanity. Composer seems less reliable to me... quirky... counter-intuitive.
Still...
Web development isn't really about *mastering* a given toolset; toolsets will change. Rather, it's about being able to adapt--to roll with the punches, as it were.
Another quick note: Composer is generally installed globally; it's gonna leverage your global PHP version, and not the version you have local to /opt/lampp/bin. Why wouldn't it? Unless you tell it that your project is dependent on the PHP libraries unique to XAMPP, it has every reason to believe you're using the global PHP version (7.2 in my case). This is a problem: I'm running 7.2 globally and D9 requires 7.3
So, let's say that at this point I have both XAMPP and Composer installed in my new VM. If, at this point, I go run a composer require on my D9 project, Composer will very quickly, in non-ambiguous terms, let me know that the version of PHP I'm running globally is incompatible with whatever I'm doing in D9. Composer's smart... in a sense; it's just not smart enough to know that my project isn't actually dependent on the global PHP version.
AskUbuntu to the rescue! The fix is to get a symlink (an alias) pointing one version of PHP to the other. What to run in the command line is in the AskUbuntu link, so I won't bother with it here. With the symlink in place, when Composer goes looking for the global PHP version, it will find the version installed under XAMPP. Cool!
Getting Composer to Play Nice with PHP
After getting my VM setup and branching out, I decided to run through the Drupal 9 upgrade instructions at Drupal.org. Initial results weren't promising. It looks as though I've got a module (or modules) that may not be D9 compatible. I'm not quite ready to troubleshoot the module (I can't even tell which one is the problem), so my next step forward will be to get the Drupal Upgrade Status module installed on the site and see if it can provide some better diagnostic info.
Unlike most other modules, the Drupal Upgrade Status module can't be installed with Drush; it needs to be installed with Composer (the deep state is out to get me--I swear!). It looks easy enough:
$ composer install --dev
$ composer require 'drupal/upgrade_status:^2.0'
Let's see what happens:
Not... enough... memoryyyyyyyy... ... ...
You'd think that the module contributors would catch on to something like this. See, turns out the memory limit in most php.ini files is about half a Gig. Composer has a built in override that will bump that to 1.5G; in order to install this module, we need to bump the limit up past about 1.6G.
Here's what did not work!!!
You can find the line of PHP in the composer.phar file (a.k.a /usr/local/bin/phar) which overrides the native php.ini memory limit, but unless you'd like to reinstall composer and begin the module install from scratch, there's a much easier way--rerun the above install as a PHP command; we can add the option -d to define an INI entry bumping the memory limit to 2G. Check it out; if we run:
$ php -d memory_limit=2G /usr/local/bin/composer require 'drupal/upgrade_status:^2.0'
// IF YOU CONTINUALLY HIT MEMORY ERRORS, YOU MIGHT JUST CALL COMPOSER THIS WAY BY
// CREATING AN ALIAS IN YOUR .bash_aliases FILE
alias composer='php -d memory_limit=2G /usr/local/bin/composer'
We get...
Success! Here, of course, the php command needs a file path after the -d option--so, we just feed it the path to Composer. This method of running Composer with inline PHP options may be something you bump into frequently. Again, you can either up the memory limit by running composer with PHP's -d option, or you could go find your php.ini file make an official change--I don't think there's a down side to that, really. Just make sure you edit the right php.ini if you have more than one. As I noted above, if you're running your server with XAMPP, you'll want to be sure that the XAMPP php.ini file is the one composer is using.
And so, the adventure continues. I'll be sure to follow up in the next few weeks with more details on the joys of a Drupal 9 upgrade. At this point, I'd classify all of this as dev-ops. None of it really has anything to do with Drupal. So, when Drupal.org claims this will be the easiest upgrade in a decade, it may very well be so--as regards Drupal. The infrastructure surrounding and supporting Drupal may be a separate question. So far, it's been nothing but headaches. Fingers crossed the Drupal Upgrade Status module helps make the transition as smooth as possible.