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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4