[Python-Dev] [Distutils] request for comments - standardization of python's purelib and platlib

Matthias Klose doko at ubuntu.com
Thu Aug 20 11:47:03 CEST 2009


On 14.08.2009 10:02, Tarek Ziadé wrote:
> On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon<brett at python.org>  wrote:
>>
>>
>> On Thu, Aug 13, 2009 at 11:23, Jan Matejek<jan.matejek at novell.com>  wrote:
>>>
>>> Hello,
>>>
>>> I'm cross-posting this to distributions at freedesktop and python-dev,
>>> because the topic is relevant to both groups and should be solved in
>>> cooperation.
>>>
>>> The issue:
>>>
>>> In Python's default configuration (on linux), both purelib (location for
>>> pure python modules) and platlib (location for platform-dependent binary
>>> extensions) point to $prefix/lib/pythonX.Y/site-packages.
>>> That is no good for two main reasons.
>>>
>>> One, python depends on the "lib" directory. (from distro's point of
>>> view, prefix is /usr, so let's talk /usr/lib) Due to this, it's
>>> impossible to install python under /usr/lib64 without heavy patching.
>>> Repeated attempts to bring python developers to acknowledge and rectify
>>> the situation have all failed (common argument here is "that would mean
>>> redesign of distutils and huge parts of whatnot").
>>
>> This is now Tarek's call, so this may or may not have changed in terms of
>> what the (now) distutils maintainer thinks.
>>
>
> I don't recall those repeated attempts , but I've been around for less
> than two years.
>
> You are very welcome to come in the Distutils-SIG ML to discuss these matters.
> I'm moving the discussion there.
>
> Among the proposals you have detailed, the sharedir way seems like the
> most simple/interesting
> one (depending on you answer to Brett's question )

The approach of splitting the installation into two different locations seems to 
be wrong, it changes the semantics for imports of python packages which are not 
installed in the same location. Simplest counter example is the use of relative 
imports, which will fail if the imported module/extension is not found in the 
same paths.

Other languages like Perl or Java don't have relative imports, or they map all 
components on the "path" into one logical path so you don't have this kind of 
problem.

I don't see an explict statement that code really has to live inside /usr/share, 
and even generated .py files differ depending on the architecture you build for 
(e.g. sip, qt bindings).

   Matthias


More information about the Python-Dev mailing list