[Python-Dev] versioned .so files for Python 3.2

[Matthias Klose]

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