Problem upgrading Sqlite3 version on CentOS for Python - python

I have CentOS 6 on my system and I'm trying to update SQLite for Python. I've installed it from source and executing sqlite --version returns version 3.33.0 as expected.
However, when I try to check the python SQLite version using import sqlite3; sqlite3.sqlite_version; I still get the previous SQLite version 3.6.20.
Software Locations:
Python 3.6.9 - /usr/bin/python3
Sqlite3 - /usr/bin/sqlite3
I've tried the solution here, this does not work at all, after updating LD_LIBRARY_PATH and checking the python SQLite version it still gives '3.6.20', and here, when I try sudo LD_RUN_PATH=, it gives me the error No such file or directory, but when I execute it without sudo LD_RUN_PATH=, it successfully compiles but still gives me SQLite '3.6.20' (Compiled python without uninstalling).
Note: I have multiple python3 versions.
What can I do to resolve this?

When I did it (specifically trying to find a way to update sqlite3 for a running python program; did not work...), I compiled sqlite and got libsqlite3.so.0.8.6, and then replaced the system-wide sqlite3 with that. For me on debian, that was in /usr/lib/x86_64-linux-gnu. I did see (though now I can't find where) that this way may cause issues when updating in the future. It did update python's sqlite3 for me though.

You can import specific versions:
__requires__= 'sqlite3==3.6.20'
import pkg_resources
pkg_resources.require("sqlite3==3.6.20")
import sqlite
Note that this only works on the first import. If sqlite gets imported before pkg_resources, it will take the latest version.

Related

Multiple versions of Sqlite3 for Python on the same server

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.
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:
python -c "import sqlite3; print(sqlite3.connect(':memory:').execute('SELECT sqlite_version();').fetchall())
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:
You'll need to build the pysqlite3 library by yourself using the Sqlite3 'amalgamation' that matches the version you want to use (more on later).
You'll need to install the library, and...
You will need to change your python script imports
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.
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.
sudo apt install python3-pip
Then,
pip install virtualenv
python3 -m venv sqlitev1 #(whatever name you want)
source sqlitev1/bin/activate
pip install pysqlite3==0.4.4 #(this can be whatever version u want)
source deactivate
python3 -m venv sqlitev2 #(whatever name you want)
source sqlitev2/bin/activate
pip install pysqlite3==0.4.4 #(this can be whatever version u want)
source deactivate
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
Compile sqlite to an alternative location
Compile Python to a different location, and point it to the custom Sqlite installation.
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
What is LD_LIBRARY_PATH and how to use it?
Set LD_LIBRARY_PATH before importing in python
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).

How to change SQLite version used by Python?

I have Python 3.8 installed alongside SQLite 3.16.2 on Debian 9.12 and I need to upgrade to a newer version of SQLite. I've downloaded and compiled the amalgamation available on the SQLite's site, and put it in /usr/bin, so when I do
$ sqlite3 --version
I get 3.32.3 in response (which is the version I compiled).
However, when I do
$ python3.8
>>> import sqlite3
>>> sqlite3.sqlite_version
I get 3.16.2, which is the earlier version. How do I change the SQLite version picked up by Python?
mkrieger1 suggested that this question may answer mine. It won't work here, as the solution provided there is directed at Python 2, not Python 3. pysqlite2 does not work with Python 3.
In my case I cannot replace with newer version because I cannot find these files. (I installed the sqlite-autoconf-3350500)
I used another manner to let it work just execute below command
export LD_LIBRARY_PATH="/usr/local/lib"
>>> import sqlite3
>>> sqlite3.sqlite_version
'3.35.5'
The way I would go around it, is by finding out the path to the old sqlite version that you are importing:
import sqlite3
print(sqlite3.__file__)
For me, this outputs:
C:\Users\YOUR_USERNAME_HERE\AppData\Local\Programs\Python\Python38\lib\sqlite3\__init__.py
Go to the lib path:
C:\Users\YOUR_USERNAME_HERE\AppData\Local\Programs\Python\Python38\lib
Then find the sqlite3 folder and delete it, then replace it with your up-to-date version. Re-try:
>>> import sqlite3
>>> sqlite3.sqlite_version
You should get your new version.

mysql-connector won't import into script in pycharm

I have successfully installed mysql-connector using pip.
Installing collected packages: mysql-connector
Running setup.py install for mysql-connector ... done
Successfully installed mysql-connector-2.1.6
However, in PyCharm when I have a script that uses the line:
import mysql-connector
PyCharm gives me an error saying there isn't a package called "mysql" installed. Is there some sort of syntax that should be used to indicate that the entire package name contains the "-" and is not just "mysql"?
When I run my script in IDLE, mysql.connector imports just fine. (I changed it to mysql-connector after seeing the "-" in the name of the package and having trouble in PyCharm.)
EDIT: per #FlyingTeller's suggestions, in the terminal, "where python" returns C:...Programs\Python\Python36-32\python.exe. "where pip" returns ...Python\Python36-32\Scripts\pip.exe. The interpreter in PyCharm for this project is this same filepath & exe as "where python" in the terminal.
Per #Tushar's comment, this program isn't using a virtual environment and the mysql-connector library is already present in the Preferences->Project->Python Interpreter.
Thanks for the feedback and any additional guidance you may be able to provide.
You need to import the connector as
import mysql.connector
Check the examples in the docs for this
If that doesn't work, then there might be an inconsistency between the interpreter that pycharm uses and the one you installed the package for. In pycharm, go to
File->Settings->Project Interpreter
In the terminal, enter
where python #Windows
which python #Linux
and also
where/which pip
make sure that the interpreter configured in pycharm is the same that appears when typing which/where python in the command line/shell. Also make sure that pip also points to the same python distribution.
It may be because you are using a virtual environment inside pyCharm, while you might have installed the library using system's default pip.
Check Preferences->Project->Python Interpreter inside Pycharm, and see if your library is listed there. If not, install it using + icon. Normally, if you use pyCharm's inbuilt terminal, it is already using the same virtual env as your project. So using pip there may help.
Usage syntax is as below:
import mysql.connector
conn = mysql.connector.connect(
user='root',
password='#####',
host='127.0.0.1',
database='some_db')
conn.close()
Go to project interpreter and download mysql-connector.You need to install it also in pycharm
I was having this exact issue as well, after a while i solved it by simply changing the name of my script in PyCharm, turns out i had named my script mysql.py (because it was my first time attempting to connect it to python) and it was critically interfering with the import.
TLDR: Change the name file if it's asssigned as mysql.py, as it takes priority over the mysql-connector and prevents it from being imported, even if installed correctly.
People have commented with reasonable responses (and I'm sure OP is good on this by now) but they weren't super clear to me...
Don't use "pip3 install" in terminal in your pycharm project. In fact, uninstall any mysql connectors you have already using this method.
So now that you have verified there are no other mysql connector packages... Add the package "mysql-connector-python" using the Python Interpreter only (in preferences) in your pycharm project. Now the package should work!

Python GDal installation

Having some problems with Gdal installation with python 2.7 on Windows 7 32bit. I am running MSVC 2010. I have followed the instruction from the blog website
http://cartometric.com/blog/2011/10/17/install-gdal-on-windows/
The installation is fine. At the end of it, I am able to run ogr2ogr in the MS-DOS and have gotten the similar screen as listed in the blog.
However, when I am trying to use the command "import osgeo" on the Python IDLE GUI shell. A series of error message is released, reading like the following
"DLL error:.........."
I believe that this might mean that the python binding is of wrong version. I have cleared up my installation by removing the following: Python-Gdal binding, Gdal, Python 2.7
After removing them, I have retried my installation with Python 3.2.3 instead and loaded the Gdal package and python binding accordingly. However, the same error returns.
Is there any intermediate steps that I could take to verify the installation. Any other advice I could have to have the bindings installed? Or is my reinstallation method correct?
I have tried to install FWTools too. It doesnt seem to work either. I have run the Python shell from EV-shell and type in "import osgeo". Have gotten the message "no module exist...."
Thanks
Get the precompiled gdal from here:
http://www.lfd.uci.edu/~gohlke/pythonlibs/#gdal
I have some other notes on setting up postgres and postgis 2.0 here if you need it:
http://monkut.webfactional.com/blog/archive/2012/5/2/using-django-14-with-gdal-19-and-postgis-20/

Accessing a MySQL database from python

I have been trying for the past several hours to find a working method of accessing a mysql database in python. The only thing that I've managed to get to compile and install is pyodbc but the necessary driver is not available for ppc leopard.
I already know about this.
UPDATE:
I've gotten setuptools to install, but now MySQL-python won't build.
UPDATE:
Now I've gotten sqlalchemy to install but while it will show up when called by the command line it won't import when used in my cgi script.
Try SQL Alchemy.
It is awesome.
Install fink. It includes the MySQLdb package.
UPDATE: Now I've gotten sqlalchemy to
install but while it will show up when
called by the command line it won't
import when used in my cgi script.
Can you verify that the Python being invoked from your CGI script is the same as the one you get when you run Python interactively? Check which python and compare it to your webserver CGI settings. That's the only thing I can think of that would cause this - getting it installed in one Python but not the other.
What OS are you on? If you're on something like Ubuntu, sudo apt-get install python-mysqldb is much more reliable than trying to build it yourself.
Also, unless I'm mistaken, SQLAlchemy won't actually help you make the connection itself if you don't have a DB-API2 module (like python-mysqldb) installed - SQLAlchemy sits at the next level up, using the DB-API2 connection and making access to it more Pythonic.

Categories

Resources