[Distutils] Adding egg support (Resource API) to existing packages
Phillip J. Eby
pje at telecommunity.com
Wed Jul 13 18:09:30 CEST 2005
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
>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
I think you're missing something. It makes more sense to bundle
ez_setup.py than pkg_resources. See this link:
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.
More information about the Distutils-SIG