[Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)

[Jeff Rush]

Paul Moore wrote:
> On 20/03/2008, zooko <zooko at zooko.com> wrote:

> I'll chime in here, too. I really want to like
> setuptools/easy_install, but I don't. I'll try to be specific in my
> reasons, in the hope that they can be addressed. I know some of these
> are "known about", but one of my meta-dislikes of setuptools is that
> known issues never seem to get addressed (I know, patches accepted,
> but I haven't got the time either...)

Clearly explained problems with the existing arrangement is valuable as well 
as patches.  Thanks for taking the time to help us see your viewpoint.


> 1. No integration with the system packager (Windows, in my case). If I
> do easy_install nose, then nose does not show up in add/remove
> programs. That significantly affects the way I manage my PC.

Part of this stems from stretching of the original mission of setuptools, to 
install modules for Python, into a general-purpose application installation 
tool.  The buildout tool is more suited for application installation, although 
not ideal yet.

In your scenario, what happens when one egg pulls in another and another, 
until you have a hundred entries in your add/remove menu?  And you don't 
understand the inter-relationship of those so you cannot do a clean uninstall?

Similarly, or what do you want to appear in that add/remove menu when you are 
using independent sandboxes with various applications in them, some of which 
are accessible only to specific users who are not admins on that box?


> 3. The pkg_resources documentation (in particular, that's the one I've
> tried to follow) is extremely hard to read. Partly this is just style,
> but it's partly because it is couched in very unfamiliar terms
> (distributions, working sets, interfaces, providers, etc). It's also
> *huge*. A tutorial style overview, supported by API detail, would be
> far better.

We'll get better docs.  Of course, that module contains roughly five different 
sets of functionality, some of which can be used unrelated to the others so 
it's not just one API.


> 4. Hard to use with limited connectivity. At work, I *only* have
> access to the internet via Internet Explorer (MS based proxy). There
> are workarounds, but ultimately "download an installer, then run it"
> is a far simpler approach for me.

This is hard to address using independent eggs re setuptools but fits buildout 
which provides for deployment of a set of related eggs as a single entity. 
I'll add it as a use case and see what we can do though.


> 5. Auto-discovery doesn't always work. I'm sorry, I really can't
> recall the example at the moment, but sometimes easy_install says it
> can't find a package I *know* is available.

I've hit a few of these myself, although it wasn't an issue with the 
auto-discovery mechanism but rather quality problems with PyPI itself.  Some 
of the eggs only had binary distributions provided, and they were not for my 
platform so couldn't be used.  Better error messages in this area would help, 
with encouragement to nag the original author to provide better data on PyPI.


> 6. Splitting the community. Windows users rely heavily on binary
> installers (at least, I do). We're starting to get a situation where
> some projects provide .egg files, and some provide traditional
> (bdist_wininst/bdist_msi) installers. This is bad. One way to do it,
> and all that :-)

Reporting and author nagging facilities built into PyPI could help encourage 
more consistent behavior.

-Jeff