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

[M.-A. Lemburg]

On 2007-05-21 22:48, Phillip J. Eby wrote:
> At 08:56 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> On 2007-05-21 20:01, Phillip J. Eby wrote:
>> > At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> >> 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).
>> >
>> > That doesn't really make sense in the context of the current PEP,
>> > though, which isn't to provide a general-purpose namespace package API;
>> > it's specifically about adding an existing piece of code to the stdlib,
>> > with its API intact.
>>
>> You seem to indicate that you're not up to discussing the concepts
>> implemented by the module and *integrating* them with the Python
>> stdlib.
> 
> No, I'm saying something else.  I'm saying it:
> 
> 1. has nothing to do with the PEP,
> 2. isn't something I'm volunteering to do, and
> 3. would only make sense to do as part of Python 3 stdlib
> reorganization, if it were done at all.

I don't understand that last part: how can adding a new module
or set of modules require waiting for reorganization of the
stdlib ?

All I'm suggesting is to reorganize the code in pkg_resources.py
a bit and move the relevant bits into pkgutil.py and into a new
eggutil.py.

> Now, the code is certainly under an open license, and the concepts are
> entirely free for anyone to use.  If somebody wishes to do what you're
> describing, they're certainly welcome to take on that thankless task.
> 
> But I personally don't see the point, since by definition that new API
> would have *no current users*.  And the purpose of the PEP is to serve
> the (rather large) audience that would like to take advantage of
> existing software that uses the API.
>
> Thus, any proposal to alter that API faces a high entry barrier to show
> how the proposed changes would provide a signficant practical benefit to
> users.

Why is that ?

You can easily provide a pkg_resource.py module with your old API
that interfaces to the new reorganized code in the stdlib.

> That's not even remotely similar to "take it or leave it".  It might
> *seem* that way, of course, simply because in any proposal to change the
> API, there's an implicit question of why nobody proposed the change via
> the Distutils-SIG, sometime during the last 2+ years of discussions
> around that API.

This doesn't have anything to do with distutils. It's entirely
about the egg distribution format.

> I remain open-minded and curious as to the possibility that someone
> *could* propose a meaningful change, but am also rationally skeptical
> that someone actually *will* come up with something that would outweigh
> the user benefit of keeping the already published, already discussed,
> already field-tested, already in-use API.
> 
> For that matter, I remain open-minded and curious as to the possibility
> of whether someone could propose a reasonable justification for *not*
> including the module in the stdlib.  After all, last year Fredrik Lundh
> surprised me with a convincing rationale for *not* including setuptools
> in the stdlib, which is why I backed off on doing so in 2.5, and am now
> proffering a much-reduced-in-scope proposal for 2.6.
>
> So, I'm perfectly willing and able to change my mind, given convincing
> reasons to do so.  So far, though, your change suggestions haven't even
> explained why *you* want them, let alone why anybody else should agree. 
> We can hardly discuss what you haven't yet said.

I'm not sure what you want to hear from me.

You asked for comments, I wrote back and gave you comments. I also
made it clear why I think that breaking up the addition into different
PEPs makes a lot of sense and why separating the code into different
modules for the same reason makes a lot of sense as well.

I also tried to stir up some discussion to make life easier
for setuptools by suggesting a user-package directory on
sys.path and adding support for namespace packages as
general Python feature instead of hiding it away in
pkg_resources.py.

You should see this as chance to introduce new concepts to Python.
Instead you seem to feel offended every time someone suggests a
change in your design. That's also the reason why I stopped
discussing things with you on the distutils list. There was simply
no way of getting through to you.

Perhaps we should just meet up for a beer in London sometime
and sort things out ;-)

Cheers,
-- 
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