[Python-Dev] PEP 0365: Adding the pkg_resources module
Phillip J. Eby
pje at telecommunity.com
Mon May 21 16:05:18 CEST 2007
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
What comments are you talking about? I must've missed them.
>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
> * 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
These items aren't directly related to the PEP,
however. 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:
(specifically, the register_namespace_handler() function.)
More information about the Python-Dev