[Distutils] Adding egg support (Resource API) to existing packages

[Phillip J. Eby]

At 11:20 AM 7/13/2005 +0100, Paul Moore wrote:
>Patching the source isn't hard, but it left me with a dilemma. I'd like to
>submit the change back to the package author, but I'm not sure how receptive
>he'd be to converting to setuptools (ie, adding a dependency on setuptools,
>changing setup.py, etc). I'd like to be able to offer a minimal change, which
>just switched to using the resource management protocol - people who wanted to
>build eggs could change setup.py, or just use the --command-packages option in
>Python 2.4.
>
>The problem is, how to depend on *just* the pkg_resources module. I can bundle
>it with the application, which is simplest, but produces a maintenance burden.

Worse - it will result in conflicts when the package is installed in an 
unmanaged way, because each package bundling pkg_resources will overwrite 
ones bundled by others.  Of course, as long as the user *only* uses 
easy_install to install packages, they'll be fine, but if they install even 
*one* package that bundles pkg_resources, they can break their installation.


>I can just say that users must install setuptools, but this seems ugly, as
>there is no obvious reason why a date utility package should depend on a setup
>utility package.

I think you're missing something.  It makes more sense to bundle 
ez_setup.py than pkg_resources.  See this link:

     http://peak.telecommunity.com/DevCenter/setuptools#using-setuptools-without-bundling-it

This will take care of ensuring that a recent setuptools is installed on 
the user's machine.  It's a relatively minor change, although it does of 
course still introduce a dependency in the sense that the package author 
needs to be comfortable with letting setuptools handle the actual installation.


>Having pkg_resources in the standard library is clearly the best long-term
>solution, but in the shorter term, shouldn't pkg_resources be unbundled from
>setuptools? In many ways, isn't that the *point* of setuptools/eggs, to ease
>unbundling of packages - and so, shouldn't setuptools "practice what it
>preaches", and unbundle itself...?

If pkg_resources could be in the standard library, there would be no need 
to tie it to setuptools.  But pkg_resources *isn't* in the standard 
library, so the best practical way to get it installed is for it to 
piggyback on setuptools, which has a bootstrap facility that'll get it 
installed.  Practicality beats purity here, I think.


>I realise that this could cause chicken and
>egg problems, where setuptools needs pkg_resources to ensure that it can
>support not having pkg_resources bundled, but even so...

You're also missing the other half of the problem, where pkg_resources 
needs setuptools so it can be installed in a way that's safe from being 
overwritten by random packages reinstalling it!  This is also why other 
packages can't bundle it, without effectively bundling setuptools too.  So, 
the simplest solution is to Just Drink the Kool-Aid and use setuptools 
already.  It's not like there aren't numerous other benefits to using it 
for your packaging, anyway.