On a Linux server, I have some Python scripts using the built-in sqlite3
module (+ some Sqlite extensions built from source, as detailed in Upgrade Python's sqlite3 on Debian).
For another Python script, I need a newer version of the Sqlite shared library than the one I already have on the system. Reason: I need Sqlite higher than 3.25.0 for Window Functions.
If I install it from source here and do make
and make install
, it will probably overwrite previous versions of this library on the server, and could potentially break other OS tools using it.
How do you handle the general problem of having multiple versions of the Sqlite shared library?
I don’t think Python virtual environments can be used for this context, or would it be possible?
Note: pip3 install --upgrade sqlite3
does not exist: we cannot upgrade Python’s built-in sqlite3
package like this. And by the way we probably should not, since it could break some OS tools using Python + sqlite3.
4
Answers
If you want 2 different version of sqlite3 (python3) on 2 different environments, you can do that.
Since you mentioned that sqlite3 is part of the std library, it seems like you can try the pysqlite3 package instead.
If you can’t run pip, run the following command first.
Then,
Now you have 2 python environments, sqlitev1 and sqlitev2, with 2 different version of sqlite3.
It might be super hacky but you can make the new version of sqlite and then make sure that the path pointing to the new version is on the pythonpath environment before the built in one. Python will scan the python path from first to last to find an import, so the new version first in the python path for the processes that want the new version and then exclude that path with the old processes that need the built in one. You can accomplish this with a bash script that loads the env and then runs the python process for the new services.
Again this is super hacky so last resort.
If you want a different version of Sqlite than that installed with your distro, and a Python that uses that version, then you could
The "pointing" is covered in the accepted answer to this question. The question body itself shows how you might compile sqlite to a custom location.
The other answer to that question proposes setting the
LD_LIBRARY_PATH
environment variable to the directory containing the custom sqlite build to avoid having to compile Python. This might work with a virtualenv (it could be set in the preactive hook, for example).See also
Another approach would be to compile pysqlite3 in a virtualenv over the custom sqlite build. You can read about this in this blog post (I won’t copy the details as it isn’t clear what licence is used by the blog).
This is very tricky and will need a little code change in your scripts.
What to do:
First, check the sqlite3 library version included with python just in case:
In my computer (python 3.8, windows) the output is
[('3.35.5',)]
which means python has the sqlite 3.35.5 library. I have no sqlite installed in my system: this is the library that comes with python3.8.IF your python sqlite3 library is not the one you need 🙁 you have an alternative: you can use the pysqlite3 instead of the
sqlite3
standard library. In this case:import pysqlite3 as sqlite3 # instead of sqlite3
Ok, what is the ‘amalgamation` and how to build pysqlite3?
The amalgamation is the whole sqlite3 library in just one .c file (with the sqlite3.h file). You can get it from the sqlite3 download page: sqlite3.36 amalgamation.
Once you have the amalgamation, follow the instructions to build statically pysqlite3, and install the package.
Now you can use pysqlite3 in your code.