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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4