Discuss lowering SQLite version requirement from 3.26 to 3.22 in Drupal 9

Another dimension to check is state of -DSQLITE_MAX_VARIABLE_NUMBER=250000

New release is out https://sqlite.org/releaselog/3_31_0.html

Probably https://www.sqlite.org/pragma.html#pragma_trusted_schema could affect all schema changes

FYI PHP 7.3 using 3.28 as default https://github.com/php/php-src/commits/PHP-7.3/ext/sqlite3/libsqlite/sql...

It does, but starting with PHP 7.4, it links against the sqlite library that's on the system, which could be 3.11 for Ubuntu 16.04 or 3.22 for Ubuntu 18.04.

I agree with #5 that 3.22 is a reasonable minimum. I think it's fine for Debian 9, Ubuntu 16.04, and RHEL 7 users to either not be able to use SQLite with Drupal 9 or else to upgrade their sqlite library.

Orthogonal to the version question, I opened #3109340: [policy] Decide whether to require json support for all database drivers for Drupal 10 to discuss whether we can require that json1 be compiled in. There's also #2, which is a separate question, but might overlap slightly in terms of whether there's any correlation between builds (either the distribution's build, or PHP 7.3's internal build) that include json1 and ones that set DSQLITE_MAX_VARIABLE_NUMBER to a large enough number.

@daffie I bet windows will use WSL in d9 era, so some Linux-distro, on MacOS this limit is higher iirc

and the variable DSQLITE_MAX_VARIABLE_NUMBER having a value of 250000 or higher

This one is problematic. The default for DSQLITE_MAX_VARIABLE_NUMBER is 999. I don't see anything in either SQLite's configure.ac or PHP 7.3's config0.m4 that sets that compiler flag to anything else.

I think this means that all or most PHP 7.3 builds will have the 999 limit. And, for PHP 7.4, it will depend on whether the operating system explicitly added that compiler flag. Debian and Ubuntu add it, but it doesn't look like CentOS does, unless it does it elsewhere than that line.

I tested on my MacOS Catalina, and found that as expected, on PHP 7.3, it's limited to 999. On PHP 7.4, I'm getting 500000, so MacOS is setting that compiler flag somewhere (I don't know where since AFAIK, MacOS source code isn't public).

So unless we're willing to restrict Drupal 9 SQLite use to only PHP 7.4+, and only on MacOS, Debian, and Ubuntu, I don't think we can require DSQLITE_MAX_VARIABLE_NUMBER higher than 999.

For anyone who wants to find out the limit on systems they have access to, here's a PHP script that tests it. It's a copy of the example in https://www.php.net/manual/en/sqlite3stmt.bindparam.php, but with :bar replaced with ?$num where $num is set in the first code line. If that number is below the limit, the script will output what https://www.php.net/manual/en/sqlite3stmt.bindparam.php says it should. If it's above the limit it, it will output nothing.

One more thing to consider here. SQLite added a real UPSERT in 3.24. As in, INSERT ... ON CONFLICT UPDATE, rather than what Drupal\Core\Database\Driver\sqlite\Upsert currently relies on, which is INSERT OR REPLACE INTO. A difference between the two is that REPLACE deletes and re-creates the entire row, so any field values not specified are reset to NULL or their default value.

I don't think that difference matters in core yet, where ->upsert() is used only by Drupal\Core\Cache\DatabaseBackend, which sets all of the field values. But maybe it could matter in contrib or in future Drupal 9 minors?

So the decision we need to make is... do we want to require 3.24 in order to be able to rely on INSERT ... ON CONFLICT UPDATE, but at the cost of leaving Ubuntu 18.04 users on PHP 7.4+ unable to use SQLite? Those users would then have to choose between not using SQLite, or using PHP 7.3, or updating to 20.04 once it's out, or manually installing a newer sqlite.

If it were MySQL or PostgreSQL, I would say that no way can we abandon Ubuntu 18.04 users, but for SQLite, since it's primarily for development and testing, maybe it's less of a big deal for developers/testers to get onto Ubuntu 20.04 or manually upgrade their sqlite installation? Tagging for release manager review of this question in particular.

And, for PHP 7.4, it will depend on whether the operating system explicitly added that compiler flag. Debian and Ubuntu add it, but it doesn't look like CentOS does

I decided to test this instead of just inferring from CentOS source code. I spun up a droplet on Digital Ocean using a base CentOS 8.1 image. I then followed the instructions on https://blog.remirepo.net/post/2019/12/03/Install-PHP-7.4-on-CentOS-RHEL... to install PHP 7.4:

dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
dnf install https://rpms.remirepo.net/enterprise/remi-release-8.rpm
dnf module reset php
dnf module install php:remi-7.4

To get sqlite into PHP, you also need to install the php-pdo package, so I did that:

dnf install php-pdo

Then, to test #14, I did:

dnf install wget
wget https://www.drupal.org/files/issues/2020-01-31/test.php_.txt
php test.php_.txt

Sure enough, it error'd out:

PHP Warning:  SQLite3::prepare(): Unable to prepare statement: 1, variable number must be between ?1 and ?999 in /tmp/test.php_.txt on line 7

While I only tried this on CentOS 8.1, I suspect it would yield the same result on RHEL 8.1 and Fedora 31.

@daffie: as per https://www.drupal.org/contribute/core/maintainers the questions you are asking belong to framework managers. @effulgentsia is already a framework manager, so you got the attention of a great person :) I swapped the tag, framework managers can remove it when they believe they provided adequate feedback.

Whether or not to require that the variable DSQLITE_MAX_VARIABLE_NUMBER has a minimum value of 250000

I'd prefer to move this to two follow-up issues:

Follow-up 1. Warn people in system_requirements() if the value is too low, this should be non-controversial and easy to commit more or less immediately, also backportable to 8.9.x and maybe 8.8.x

Folllow-up 2. Decide whether to make it a hard requirement in 9.0.x or 10.0.x

On 3.25: For me personally I think requiring 3.25 at the expense of Ubuntu 18.04 users is OK. The release date for Ubuntu 20.04 is April 2020, and that is definitely going to happen before Drupal 9.0.0. Since we are mainly talking about people's development environments here rather than site hosting, needing to be on the latest Ubuntu LTS (or getting a higher version of sqlite via some other route) is pretty reasonable and a good trade-off for being able to fix otherwise-unfixable bugs in the driver (although sounds like not the end of the world if we delayed that fix to 10.0.x either).

@catch: I was looking to open the first followup but apparently #2031261: Make SQLite faster by combining multiple inserts and updates in a single query provides a sensible workaround even for lower numbers. I think that may be the issue to add a warning, given that the workaround makes things work but is not the optimal behaviour. It also does not look like raising SQLite version requirements raises that number.

OK great let's continue the variable limit work in #2031261: Make SQLite faster by combining multiple inserts and updates in a single query and can ignore it here.

Uploading 2 patches: one that sets the minimum version to 3.22 and one that sets it to 3.26. I'm curious whether DrupalCI will pass the first and fail the second.

For me personally I think requiring 3.25 ... is OK

If we're ok with 3.25, then I recommend going to 3.26, because I don't think there's any operating system distribution that ships with 3.25. Therefore, it'll be easier for DrupalCI to test on 3.26 as that's the one that comes with RHEL/CentOS 8. Also, it means that that'll continue to have secure builds available (provided by CentOS) until 2024.

I posted #23 because I was concerned that DrupalCI currently tests on Ubuntu, so I thought it would allow us to go as high as 3.22 but no higher. However, looks like that's not true. The "PHP 7.4 & SQLite 3.8" test is actually testing on Debian 8, which is the OS that ships with SQLite 3.8, so it's failing both patches. But if DrupalCI can run a docker image with Debian 8, then presumably it can also run a Docker image with CentOS 8, in which case it can test SQLite 3.26. But I think this means that to actually bump the minimum to 3.26 that we need to add that image to DrupalCI. If someone knows where to file an issue to request that change/addition to DrupalCI, please do. Otherwise, I'll figure it out and do it tomorrow.

So the queue is https://www.drupal.org/project/issues/drupalci_environments. I went ahead and opened an issue at #3112396: DrupalCI environment needed with PHP 7.4 and SQLite >= 3.26 making it clear we're not 100% finalized here yet.

To be able to commit a core patch, we just need to be able to run tests on a supported version of sqlite, min/max environments can come later.

I reworked the issue summary. I hope it's helpful for whoever else is needed to make the decision.

I'm +1 to raising the minimum version to 3.26, so removing the "Needs framework manager review" tag.

As noted in the issue summary, I think the key to that being acceptable is that people on the non-latest OS version can use PHP 7.3. However, those people will be running with a SQLITE_MAX_VARIABLE_NUMBER at its default of 999, so I don't think we should require anything higher than that, and instead get the workaround in #2031261: Make SQLite faster by combining multiple inserts and updates in a single query to a committable state.

@effulgentsia: re who needs to decide IMHO that would be framework and release managers. Thanks for the framework manager signoff. What we usually did before is we opened an actual issue to raise the requirement once the technical possibilities were there (in this case the sqlite environment for PHP 7.4 and #2031261: Make SQLite faster by combining multiple inserts and updates in a single query would IMHO be considered a requirement). We can also convert this issue to a not-policy issue, if we think 3.26 is it for Drupal 9 and continue as an implementation issue that is postponed on those two things. In that case #3112396: DrupalCI environment needed with PHP 7.4 and SQLite >= 3.26 should be informed to go ahead :)

Ok converted to an implementation issue since it does not seem like we would raise it further later (ie. we don't need the policy issues after the implementation issue) :)

FWIW I'm also +1 on requiring 3.26 given the IS writeup and the available distro support.

I can't find anything from SQLite themselves about their support policy for minor versions; does anyone have a reference?

Per @effulgentsia their release history is the best indicator he found either (and it doesn't seem to include any backports of security patches or whatnot). OTOH they also don't seem to have a fixed schedule at all. So I think setting the requirement based on "all distros have a version that has support for it" and "has useful technical features/bug fixes" is good. Edit: Said release history is at: https://www.sqlite.org/changes.html

Confirmed @catch is also alright with increasing the requirement to 3.26 for D9.

Updated #3112396: DrupalCI environment needed with PHP 7.4 and SQLite >= 3.26 following the above decision. Looks like #2031261: Make SQLite faster by combining multiple inserts and updates in a single query should not be a beta requirement then? (It is honestly not clear to me at all from the above if we are loosing on the max variable numbers by upgrading SQLite requirements or just not gaining anything?)

Here's a patch.

Re #38 I since got confirmation from @xjm et. al. that #2031261: Make SQLite faster by combining multiple inserts and updates in a single query is a pre-existing condition that is not made better or worse here. So that is not blocking.

Looks like this cannot get to RTBC without #3112396: DrupalCI environment needed with PHP 7.4 and SQLite >= 3.26 first being rolled out. That said, I don't believe this is considered a beta must-have ATM.

Note that #39 passes on PHP 7.3, because PHP 7.3 bundles its own SQLite with a high enough version. Given that, would it make sense to commit it while we wait for #3112396: DrupalCI environment needed with PHP 7.4 and SQLite >= 3.26, or is it not acceptable for HEAD to be in an interim state where we can't test a PHP 7.4 + SQLite combination?

IMO we can commit and add the combination later.

Committed 19cf46c and pushed to 9.0.x. Thanks!

#3112396: DrupalCI environment needed with PHP 7.4 and SQLite >= 3.26 is a shame but I agree with @catch I don't think that should stop us going forward.

How can it not stop us going forward? We literally cannot test SQLite on D9 at all now that this has been committed.

My suggestion in the previous meeting was for this to be a beta target if the CI environments did not support it, since it's only a minor version update. I think this needs to be reverted, but can be allowed during beta.

See here: https://www.drupal.org/pift-ci-job/1602293

According to @Mixologic the UI label might be lying and it additionally looks like #3109534: Raise the minimum MySQL version to 5.7.8 and MariaDB version to 10.2.7 in Drupal 9 might have actually been the thing that broke SQLite (as well as postgres), which is... counterintuitive. Reverting that now to verify.

Just to confirm the UI label is lying #3107155-38: Discuss lowering SQLite version requirement from 3.26 to 3.22 in Drupal 9 properly passed on PHP 7.3

The one thing we can't do is test PHP 7.4 and sqlite.

The UI label is semi-true. Version 3.8 is the version that's on the operating system. It's just that PHP 7.3 ignores what's on the operating system and uses its own bundled copy of SQLite 3.28.

I am afraid this needs to be reverted as this fails tests on PHP 7.4 DrupalCI testbot

The database server version 3.8.7.1 is less than the minimum required version 3.26.

We should have PHP 7.4 containers upgraded to a newer sqlite3 library

Note that this was found via #3109534-76: Raise the minimum MySQL version to 5.7.8 and MariaDB version to 10.2.7 in Drupal 9.

Not sure fixing the test environments would be enough, given that people could encounter the same mismatch of versions locally in which case it would still fail, so we to fix the db layer in Drupal to not freak out about invalid combinations of DB backends if at least a valid one is available probably.

Could we make the quickstart test only run on sqlite environments?

Reverted for now to get the PHP 7.4 environment back to green.

Maybe this.

+++ b/core/tests/Drupal/KernelTests/Core/Command/QuickStartTest.php
@@ -21,7 +21,7 @@
-class QuickStartTest extends TestCase {
+class QuickStartTest extends KernelTestBase {

@@ -88,6 +88,10 @@ public function testQuickStartCommand() {
+    if ($this->testDb::getConnection()->driver() !== 'sqlite') {
+      $this->markTestSkipped();
+    }

QucikStartTest can't be a kernel test - it can't have any Drupal environment stuff like this. If we want to skip the test then we need to skip on PHP version because this quick start site being installed and tested is always using SQLite.

Could we use a non-Drupal API to check the SQLite version? Skipping on PHP version would be super fragile because the relationship between the environment and the SQLite version could change at any time.

It looks at though https://www.php.net/manual/en/sqlite3.version.php will do the trick. For me locally on PHP 7.3 this returns

Array
(
    [versionString] => 3.31.1
    [versionNumber] => 3031001
)

It's the same on PHP 7.4 for me too but my locally PHP is built against the same sqlite.

@TravisCarden is going to work on implementing #60.

SQLite3::version() is a good find.

Uploading two patches. One hard-codes 3.26 in the test. The other instantiates Drupal\Database\Driver\sqlite\Install\Tasks and gets the minimum version from there.

Unfortunately this did not skip the test on MySQL :(

The second version didn't, at least. The first version didn't get run against an environment with old SQLite. I queued the first version against the additional environments.

(NR because the first version might still work?)

It's because two more test methods needed to be skipped.

I think using the version from install tasks is going to be the way to go here, so updated version for that. Tiny patch so not bothering with an interdiff.

If #66 passes -- we should probably add a a comment explaining why we have to skip the tests followed by a @todo referencing #3112396: DrupalCI environment needed with PHP 7.4 and SQLite >= 3.26.

I'm not sure we should add the @todo to that issue. The problem here is that we have a test with a dependency on sqlite, that runs when we're only supposed to be running MySQL tests. So skipping it seems the right thing in general, it's just that it's happened to pass until now.

If you don't have the sqlite extension at all, the test will fail too (either because the SQLite3 class doesn't exist with the patch so you'll get a fatal error, or in HEAD because it can't install Drupal without sqlite being available).

In #3107155-56: Discuss lowering SQLite version requirement from 3.26 to 3.22 in Drupal 9 I was trying to detect whether we're in an sqlite or mysql environment, but using a Kernel test was a no go.

I'm wondering if we could rely on SIMPLETEST_DB - then we could determine whether we're trying to run MySQL or sqlite tests and skip based on that rather than the version.

Here's a patch relying on $_ENV['SIMPLETEST_DB'].

#68 seems like another case for #3110546: Allow contributed modules (mostly database drivers) to override tests in core

This seems fine to me for the purposes of the 9.0.x beta.

I'm not sure about #68. Quickstart command tests should be test database independent. Quickstart uses sqlite. The test database is irrelevant. #66 failed on PHP 7.4 for a known random fail - #3115000: Random fail in \Drupal\Tests\node\Functional\PagePreviewTest::testPagePreviewWithRevisions on PHP 7.4. I think #66 is the correct stopgap because the moment PHP7.4 containers are updated then it'll work.

We allow sites (and by extension development environments) to run without sqlite available, so therefore our tests should also pass without it available - so we should not assume that it's always there.

#3107155-66: Discuss lowering SQLite version requirement from 3.26 to 3.22 in Drupal 9 with a class_exists() in addition to the version check might be fine though?

We allow sites (and by extension development environments) to run without sqlite available, so therefore our tests should also pass without it available - so we should not assume that it's always there.

Agreed with this either way.

We allow sites (and by extension development environments) to run without sqlite available,

Sure but that's not our test coverage. What our test environments have installed is up to us. I don't think we're promising our tests will run successfully in any environment Drupal supports. There would be many many more fails than just this.

The InstallCommand has the following code

    if (!extension_loaded('pdo_sqlite')) {
      $io->getErrorStyle()->error('You must have the pdo_sqlite PHP extension installed. See core/INSTALL.sqlite.txt for instructions.');
      return 1;
    }

So I think you're right we can use #66 plus a @requires extension pdo_sqlite on the test classes.

Re-rolled for the MySQL issue landing - conflicts in INSTALL.txt - and updating for #75.

Correct patch this time.

+++ b/core/tests/Drupal/BuildTests/Framework/Tests/HtRouterTest.php
@@ -14,6 +16,11 @@ class HtRouterTest extends QuickStartTestBase {
+   $tasks = new Tasks();
+    if (version_compare(\SQLite3::version()['versionString'], $tasks->minimumVersion()) < 0) {
+      $this->markTestSkipped();
+    }

V minor nit. Indentation of $tasks.

Also tempting to add this as a constant to \Drupal\Core\Database\Driver\sqlite\Install\Tasks - like we have \Drupal\Core\Database\Driver\mysql\Install\Tasks::MYSQL_MINIMUM_VERSION. So we don't to construct an object here.

WidgetUploadTest bit us, so requeueing.

NW for #78.

Fix #78 and mentioned json support as we already added the same to mysql (solves #10-13 comments)

That looks correct to me. Nice and clean. It also addresses previous feedback, fails on expected databases, and passes on the rest.

Committed 27987af and pushed to 9.0.x. Thanks!

All looks good. The containers have already been updated so actually this is now passing and running the tests on all supported environments. But it's still a good change to make. It'd be great to fix #2905007: Allow run-tests.sh to report skipped/risky/incomplete PHPUnit-based tests so we can confirm whether a test is skipped or passed on DrupalCI but I've confirmed locally that these tests are running when the requirements are met.

This is missing a change record. It should also be mentioned in the release notes.

Created change record and published it - plus added release note.

Has anyone tested SQLite+PHP 7.3+Drupal 9 with Ubuntu 18.04? I can't get it to work - there's no official package for SQLite newer than 3.22, so I think the only way to get this working is to compile SQLite and PHP. IMO Drupal 9 and SQLite should work on 18.04 since it's the newest LTS release.

Ubuntu 20.04 is due for release April 23rd, several weeks before Drupal 9.0.0 will come out. So we are incompatible for the next month (at least without some fiddling), but then compatible with the LTS again.

Note this is also documented in the issue summary.

@catch This statement from the issue summary is incorrect then "However, they too can use PHP 7.3 until they're able to upgrade their OS"

Edit: Also worth noting that 18.04 is supported until Apr 2023

We could consider a contrib driver to intermediately support older versions of SQLite, like we've added for MySQL 5.6?

Has anyone tested SQLite+PHP 7.3 with Ubuntu 18.04?

I thought I did, but when I tried it again just now, you're right that if you use ppa:ondrej/php to get PHP 7.3, then SQLite is at version 3.22. In other words, that package compiles against the sqlite that's on the system, rather than PHP 7.3's default of its own copy of sqlite 3.28. And when I check what's on a fresh install of Debian 10, then its PHP 7.3 has SQLite 3.27, which also means it's using the one on the system rather than PHP 7.3's copy of 3.28.

Note that TravisCI on Ubuntu 18.04 uses a PHP 7.3 build that uses PHP 7.3's default SQLite 3.28 copy, which might be related to it using phpenv to manage its PHP versions.

IMO Drupal 9 and SQLite should work on 18.04 since it's the newest LTS release.

I agree. I think we should lower the SQLite minimum in core to 3.22. I think it's fine to lower requirements between beta and RC. My rationale for thinking 3.26 was ok was based on an assumption that the most common ways to have PHP 7.3 on Ubuntu 18.04 used PHP's default of compiling with its copy of SQLite 3.28. But if the most official PHP 7.3 package for Ubuntu 18.04 compiles in SQLite 3.22, then I think that's what core should support.

It's a shame, because UPSERTs would have been nice, but I think we can continue to work around not having that.

@effulgentsia is that really necessary when Ubuntu 20.04 will be out in 3-4 weeks?

Another option would be to try and fix this upstream in ppa:ondrej/php, if anyone has experience with building debian packages :)

Re-opening while we discuss.

Another option would be to try and fix this upstream in ppa:ondrej/php, if anyone has experience with building debian packages :)

I doubt they'd accept it. I suspect it's intentional on their part to use the sqlite that's on the system.

Has anyone tested SQLite+PHP 7.3+Drupal 9 with Ubuntu 18.04? I can't get it to work - there's no official package for SQLite newer than 3.22, so I think the only way to get this working is to compile SQLite and PHP.

@samuel.mortenson: Well, Ubuntu 20.04 (focal) is a pretty official package repository, so does this work for you:

sudo echo "deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse" >> /etc/apt/sources.list
sudo apt-get update
sudo apt-get -y install sqlite3/focal

In my testing, it does, and does not require recompiling PHP. However, I don't know enough about Ubuntu to know if the above is a legitimate thing to ask Ubuntu users to do. Anyone know if having an Ubuntu focal repository as an additional item in sources.list on a Ubuntu bionic system will mess anything up? For example, unintentionally pulling other packages in that you don't want? I would hope that it wouldn't without you explicitly asking for "/focal" like in the last line of the above.

I'm OK with lowering the SQLite version requirement to 3.22 in principle, although that means we'll have to figure out what to do with the CI environments all over again.

@effulgentsia After you ran that, did you confirm that the SQLite version used by PHP (using something like php -i) was correct? AFAIK you'd also need to update the SQLite PHP extension, not just the SQLite package.

Edit: Re-read your comment, re-writing mine.

did you confirm that the SQLite version used by PHP (using something like php -i) was correct?

Yes. Starting from a brand new Ubuntu 18.04.3 droplet on Digital Ocean, here's what I get:

(output from commands is indented for clarity)

sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo apt install php7.3 php7.3-common php7.3-sqlite

php --version
  PHP 7.3.16-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Mar 20 2020 13:51:46) ( NTS )
  ...

php -i | grep "SQLite Library"
  SQLite Library => 3.22.0
  SQLite Library => 3.22.0
  
sudo echo "deb http://archive.ubuntu.com/ubuntu focal main restricted universe multiverse" >> /etc/apt/sources.list
sudo apt-get update
sudo apt-get -y install sqlite3/focal

php --version
  PHP 7.3.16-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Mar 20 2020 13:51:46) ( NTS )
  ...
  
php -i | grep "SQLite Library"
  SQLite Library => 3.31.1
  SQLite Library => 3.31.1

AFAIK you'd also need to update the SQLite PHP extension, not just the SQLite package.

The reason I think the above works is that the whole point of compiling/building PHP to use the SQLite that's on the system rather than PHP's default bundled copy of SQLite 3.28 is, you know, to actually use the SQLite that's on the system, so I'm guessing it links to that dynamically, and does not require recompilation when what's on the system changes. Alternatively, maybe Ubuntu's package manager is smart enough to rebuild all dependents automatically, though I see no indication that it's doing that in this case.

@effulgentsia Great, thanks for testing again - if that's documented and safe on 18.04 I don't think there's as much pressure to lower the requirement.

Maybe just update change record with this workaround?

if that's documented and safe on 18.04

I really can't vouch for its safety. I asked some co-workers, and they expressed unease about mixing Bionic and Focal repositories in sources.list. I think those commands are probably safe enough for something like DrupalCI or TravisCI, but without understanding the repercussions more, I'd be hesitant to recommend them for someone's personal computer.

@effulgentsia is that really necessary when Ubuntu 20.04 will be out in 3-4 weeks?

That's only for new installs. People already on 18.04 won't be prompted to upgrade until July. People on downstream distros like Mint and ElementaryOS will need to wait until those have upgrades.

I have absolutely no problem with adding a fallback driver for SQLite.

Thanks for offering! I think this might be an acceptable solution. The only caveat here though is that in this case, the driver has to be named 'sqlite', because that's hard-coded in InstallCommand::install(), unless we fix that to not hard-code it.

We'll also need to update the docs page for Quick Start, where instead of:

mkdir drupal && cd drupal && curl -sSL https://www.drupal.org/download-latest/tar.gz | tar -xz --strip-components=1
php ./core/scripts/drupal quick-start demo_umami

We'll need to add a line in between those two for Ubuntu 18.04 users for the command to run to get the contrib sqlite driver into their codebase.

People already on 18.04 won't be prompted to upgrade until July.

That's still only a month from Drupal 9.0.0's release, for an issue that is only really going to impact local development.

Its a dev dependency. That means the community for this is already somewhat techie. I don't see any concern leaving the sqlite version as-is.

As an Ubuntu 18.04 user, I just got this error message after trying to install with Quick Start:

$ mkdir drupal && cd drupal && curl -sSL https://www.drupal.org/download-latest/tar.gz | tar -xz --strip-components=1
$ php ./core/scripts/drupal quick-start demo_umami
 0/17 [░░░░░░░░░░░░░░░░░░░░░░░░░░░░]
Installing Drupal

In install.core.inc line 964:

Resolve all issues below to continue the installation. For help configuring your database server, see the installation handbook, or contact your hosting provider.

• The database server version 3.22.0 is less than the minimum required version 3.26.

quick-start [--langcode [LANGCODE]] [--site-name [SITE-NAME]] [--host [HOST]] [--port [PORT]] [-s|--suppress-login] [--] [<install-profile>]

$ php -v
PHP 7.3.19-1+ubuntu18.04.1+deb.sury.org+1 (cli) (built: Jun 12 2020 07:48:30) ( NTS )

$ php -i | grep "SQLite Library"
SQLite Library => 3.22.0
SQLite Library => 3.22.0

[...] you're right that if you use ppa:ondrej/php to get PHP 7.3, then SQLite is at version 3.22

I have upgraded to PHP 7.3 with ppa:ondrej/php, and do seem to have SQLite 3.22.

Usually, I don't install the latest LTS Ubuntu release (16.04, 18.04, 20.04, etc.) right after it is released, but wait up to half a year, for all the bugs to get fixed and a few service packs are released to fix them. So I vote for lowering the SQLite requirement to 3.22, if it is possible.

Downgrading from critical - this is a developer-facing issue only, and becomes less of an issue as time passes due to Ubuntu 20.04 having been out longer.

While I still don't think it's necessary to make this change, I don't think there's a particular problem if we do so.

It is of course possible for Ubuntu 18.04 users to upgrade to 20.04 at any point now, but it is technically not required until 2023:

An Ubuntu LTS is a commitment from Canonical to support and maintain a version of Ubuntu for five years.

What is an Ubuntu LTS release?

So as if @catch write "I don't think there's a particular problem if we do so" I still vote for it.

Good option is #105 - update instructions for quickstart command.

Moreover for quickstart there's official docker images!

When someone using LTS version it's really strange to see that external repositories used...
Why you're sticking to LTS when your system has non-lts components?

@andypost: I stick to Ubuntu LTS for stability, and only upgraded to PHP 7.3 to bypass Composer issues with un-resolvable PHP version requirements (Your requirements could not be resolved [...] drupal/core 9.0.2 requires php >=7.3 -> your PHP version (7.2.32) does not satisfy that requirement.) since Composer is checking against the host PHP version, not Lando, when I initially run composer create-project drupal/recommended-project.

There is a chicken/egg situation, since I need to be in the Drupal folder, fire up lando init, and start Lando before I can use lando composer, which will use Lando's PHP version (7.3). Supposedly you can override Composer PHP version by defining it in the .composer/config.json file, but it doesn't seem to get picked up ... I also know of the --ignore-platform-reqs flag, but it doesn't seem ideal.

Like I wrote, I usually wait for the first point release of Ubuntu (in this case Ubuntu 20.04.1 LTS) before I consider upgrading, or do a fresh install, which should be released August 6th 2020.

+1, good call here IMO. I ran into this issue once with github's action in the past few weeks, using their default ubuntu runner. But that "latest" version is about to jump from 18.04 => 20.04 soon. And many other toolings in the marketplace have also made that jump too.