[Python-Dev] versioned .so files for Python 3.2 (original) (raw)

Matthias Klose doko at ubuntu.com
Sat Jun 26 22:45:54 CEST 2010

On 25.06.2010 20:58, Brett Cannon wrote:

On Fri, Jun 25, 2010 at 01:53, Scott Dial

Placing .so files together does not simplify that install process in any way. You will still have to handle such packages in a special way. You must still compile the package multiple times for each relevant version of python (with special tagging that I imagine distutils can take care of) and, worse yet, you have created a more trick install than merely having multiple search paths (e.g., installing/uninstalling lxml for one version of python is actually more difficult in this scheme). This is meant to be used by distros in a programmatic fashion, so my response is "so what?" Their package management system is going to maintain the directory, not a person. You and I are not going to be using this for anything. This is purely meant for Linux OS vendors (maybe OS X) to manage their installs through their package software. I honestly do not expect human beings to be mucking around with these installs (and I suspect Barry doesn't either).

Placing files for a distribution in a version-independent path does help distributions handling file conflicts, detecting duplicates and with moving files between different (distribution) packages.

Having non-conflicting extension names is a schema which already is used on some platforms (debug builds on Windows). The question for me is, if just a renaming of the .so files is acceptable for upstream, or if distributors should implement this on their own, as something like:

if ext_path.startswith('/usr/') and not ext_path.startswith('/usr/local/'): load_ext('foo.2.6.so') else: load_ext('foo.so')

I fear this will cause issues when e.g. virtualenv environments start copying parts from the system installation instead of symlinking it.

Matthias

More information about the Python-Dev mailing list