-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use a modern version of SQLite3 #93
Conversation
If you build a python module with a recent version of sqlite3 we expect that the module has no build dependency (does not directly link to libsqlite3 via a compiled extension) but instead uses the pure Python API, right? In that case it should note be a problem to use a more recent version in the manylinux docker container. |
@ogrisel: Yes, this is in the context of using the pure Python API only, not directly linking to libsqlite3. The problem is that the old sqlite3 in Centos5 doesn't accept certain newer commands in Sqlite3's dialect of SQL, but such SQL commands are just sent from Python to Sqlite3 as strings. |
@ogrisel: Yes, libsqlite3.so ends up in /usr/local/lib. |
@ogrisel: I put the new sqlite3 in "/usr/local/lib" rather than "/usr/lib" for the benefit of any Centos 5 packages that depend on sqlite3. Also, if I had installed in "/usr/lib" then I'd have clobbered files that should be under the package manager's control. Given your setup, it might make the most sense to set the prefix to something in "/opt", say, "/opt/sqlite3" but then of course you'd need to add a flag to each Python configuration script to make it find that version --- with "/usr/local" this is automatic. |
I think using "/usr/local/lib" is good if Python can find there by default. |
No objection. |
Ok merged. |
* update openssl fetch Committer: Robin Becker <robin@reportlab.com> * Use $TRAVIS_COMMIT as image tag * Use TRAVIS_COMMIT in deploy.sh * Empty commit to trigger update to auditwheel 1.5.0 (pypa#81) * Patch libc headers to make them compatible with C99 inline semantics Closes: pypa#86 * Add 3.6.0 to CPython versions to build Closes pypagh-82 * Update to latest bugfix releases of older Python versions * FIX missing symlink to pip Also make sure that calls to rm never ask for interactive confirmation. * Use Python 3.6 to install certifi and auditwheel * Split travis build into 2 parallel jobs * Use the trusty image This is hopefully a workaround to use the docker service with a build matrix: travis-ci/travis-ci#5448 * Update to Python 3.4.6 and Python 3.5.3 * Update OPENSSL_ROOT to latest release [k] (current specified one [j] does not exist anymore in the OPENSSL_DOWNLOAD_URL ftp repo.) * README: python 3.6 * BF: use vault repositories for EOL CentOS 5 Main repositories for CentOS 5 now offline; point yum at vault.centos.org (via IP to specialize to a particular server). * Reference specific 5.11 release instead of version 5 Also switched the IP address for the DNS name to avoid any future surprises. Fixes pypa#103 Credit for this fix goes out to Ryan Walker (@ryandub) and Lars Butler (@larsbutler). * Changed build.sh to compile SQLite3 from source and install in /usr/local. (pypa#93) * Bundle copy of epel-release-5.4.noarch.rpm
This patch has "build.sh" install a recent version of SQLite3 (3.16.2) into /usr/local/lib prior to building all the Pythons. The motivation is two-fold:
First, it fixes issue sqlite3 is broken under Python 3.6 #90, namely that sqlite3 is broken under Python 3.6.
Second, the version of SQLite3 that comes with Centos5 is very old, prior to the signifiant changes of SQLite 3.6.0 which itself was released in mid-2008. This causes problems when building a Python module that relies on any of these SQLite features, since (a) one can't run the doctests and (b) things like Sphinx's autodoc only work if you can actually import the module.
I have successfully tested the resulting Docker container by building wheels for this project.