[Python-Dev] PEP 0365: Adding the pkg_resources module (original) (raw)

M.-A. Lemburg mal at egenix.com
Mon May 21 18:28:30 CEST 2007

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 pkgresources 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.

pkgresources 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, pkgresources provides a more PEP 302-compatible alternative to pkgutil.extendpath(). pkgutil doesn't support anything but existing filesystem directories, but the pkgresources 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 registernamespacehandler() 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

More information about the Python-Dev mailing list