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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
