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-... 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.