[Python-Dev] PEP: per user site-packages directory

[M.-A. Lemburg]

I don't really understand what all this has to do with per user
site-packages.

Note that the motivation for having per user site-packages
was to:

 * address a common request by Python extension package users,

 * get rid off the hackery done by setuptools in order
   to provide this.

As such the PEP can also be seen as an effort to enable code
cleanup *before* adding e.g. pkg_resources to the stdlib.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jan 22 2008)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

:::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611


On 2008-01-21 16:06, Nick Coghlan wrote:
> Steve Holden wrote:
>> Christian Heimes wrote:
>>> Steve Holden wrote:
>>>> Maybe once we get easy_install as a part of the core (so there's no need
>>>> to find and run ez_setup.py to start with) things will start to improve.
>>>> This is an issue the whole developer community needs to take seriously
>>>> if we are interested in increasing take-up.
>>> setuptools and easy_install won't be included in Python 2.6 and 3.0:
>>> http://www.python.org/dev/peps/pep-0365/
>>>
>> Yes, and yet another release (two releases) will go out without easy 
>> access to the functionality in Pypi. PEP 365 is a good start, but Pypi 
>> loses much of its point until new Python users get access to it "out of 
>> the box". I also appreciate that resource limitations are standing in 
>> the way of setuptools' inclusion (is there something I can do about 
>> that?) Just to hammer the point home, however ...
> 
> Have another look at the rationale given in PEP 365 - it isn't the 
> resourcing to do the work that's a problem, but the relatively slow 
> release cycle of the core.
> 
> By including pkg_resources in the core (with the addition of access to 
> pure Python modules and packages on PyPI), we would get a simple, stable 
> base for Python packaging to work from, and put users a single standard 
> command away from the more advanced (but also more volatile) features of 
> easy_install and friends.
> 
> Cheers,
> Nick.
>