Coveragepy: Coverage 5.0 fails for python3 installations lacking sqlite3

[calebmayeux]

Describe the bug
Coverage 5.0 doesn't explicitly have a requirement on sqlite3, which causes it to successfully install but fail when running in a python3 instance that doesn't have sqlite3 installed.

Example stacktrace:
File "lib/python3.7/site-packages/coverage/sqldata.py", line 15, in
00:01:17.336 import sqlite3
00:01:17.336 File "lib/python3.7/sqlite3/__init__.py", line 23, in
00:01:17.336 from sqlite3.dbapi2 import *
00:01:17.336 File "lib/python3.7/sqlite3/dbapi2.py", line 27, in
00:01:17.336 from _sqlite3 import *
00:01:17.336 ModuleNotFoundError: No module named '_sqlite3'

To Reproduce
Install python from source (so it doesn't have sqlite3 automatically installed). Using these versions.
python 3.7.4
Coverage 5.0

Expected behavior
Expect the installation of coverage to install sqlite3 since it's a dependency and expect to not hit the missing package exception.

Additional context
python 3 installations installed from source don't automatically include sqlite3 unless you provide some other parameters to them. I assume this was missed because most people's installations have sqlite3 by default and thus don't hit this issue of the implied dependency.

[nedbat]

Unless I'm missing something, there's no way for coverage.py to install sqlite3. It's not a package on PyPI that can be installed. It has to be built when Python is built.

I can change the behavior so that the error is clearer, but unless you have an idea of how to install sqlite3 after the fact, that's about all I can do.

[calebmayeux]

Huh, unfortunately I believe you are correct @nedbat . Thanks for the quick response!

For any others who stumble upon this, I for one am pinning version to 4.5.4 like mozbhearsum did for the immediate term and gonna rebuild my pythons with sqlite to move forward (building from source since CentOS python packages lag way behind python releases).