[Python-Dev] PEP 0365: Adding the pkg_resources module

[M.-A. Lemburg]

On 2007-05-21 16:05, Phillip J. Eby wrote:
> At 01:43 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> On 2007-05-21 00:07, Talin wrote:
>>> Phillip J. Eby wrote:
>>>> I wanted to get this in before the Py3K PEP deadline, since this is a
>>>> Python 2.6 PEP that would presumably impact 3.x as 
>> well.  Feedback welcome.
>>>>
>>>> PEP: 365
>>>> Title: Adding the pkg_resources module
>>> I'm really surprised that there hasn't been more comment on this.
>> True.... both ways, I guess: I'm still waiting for a reply to my
>> comments.
> 
> What comments are you talking about?  I must've missed them.

I've attached the email. Please see below.

>> I'd also like to see more discussion about adding e.g.:
>>
>>  * support for user packages
>>
>>    (ie. having site.py add a well-defined user home directory
>>    based Python path entry to sys.path, e.g.
>>    ~/.python/user-packages, much like what MacPython already does
>>    now)
>>
>>  * support for having the import mechanism play nice
>>    with namespace packages
>>
>>    (ie. packages that may live in different places on the disk,
>>    but appear to be in the same Python package as seen by the
>>    import mechanism)
>>
>> I think those two features would go a long way in reducing the
>> number of hacks setuptools currently applies to get this
>> functionality working with code in .pth files, monkey-patching
>> site.py, etc.
> 
> These items aren't directly related to the PEP, 
> however. 

Right. I wasn't referring to this PEP. I think we should have
two more PEPs covering the above points, since they offer
benefits for all users, not just setuptools users.

> pkg_resources doesn't monkeypatch anything or touch any 
> .pth files.  It only changes sys.path at runtime if you explicitly 
> ask it to locate and activate packages for you.
>
> As for namespace packages, pkg_resources provides a more PEP 
> 302-compatible alternative to pkgutil.extend_path().  pkgutil doesn't 
> support anything but existing filesystem directories, but the 
> pkg_resources version supports zipfiles and has hooks to allow 
> namespace package support to be registered for any PEP 302 importer.  See:
> 
> http://peak.telecommunity.com/DevCenter/PkgResources#supporting-custom-importers
> 
> (specifically, the register_namespace_handler() function.)

Looking at the code it appears as if you've already formalized
an implementation for this.

However, since this is not egg-specific it should probably be
moved to pkgutil and get a separate PEP with detailed documentation
(the link you provided doesn't really explain the concepts, reading
the code helped a bit).

What I don't understand about your approach is why importers
would have to register with the namespace implementation.

This doesn't seem necessary, since the package __path__ attribute
already provides all functionality needed for redirecting
lookups to different paths.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 21 2007)
>>> 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
-------------- next part --------------
An embedded message was scrubbed...
From: "M.-A. Lemburg" <mal at egenix.com>
Subject: Re: [Python-Dev] PEP 0365: Adding the pkg_resources module
Date: Fri, 04 May 2007 16:06:54 +0200
Size: 10406
Url: http://mail.python.org/pipermail/python-dev/attachments/20070521/73a3d884/attachment-0001.mht