[Distutils] EasyInstall: bootstrapping
ianb at colorstudy.com
Sat Jun 4 23:05:09 CEST 2005
Phillip J. Eby wrote:
> Hm. I would suggest that the safest tack to take is try importing
> pkg_resources and do a 'require()' for the setuptools version that you
> need. If the import fails or the version fails, bail out of setup.py,
> asking for the user to install the correct setuptools. I think that
> trying to invoke easy_install recursively or guess where the egg should
> be installed is a bad idea. (E.g., guessing about the egg location will
> cause easy_install's sandboxing to shut you down anyway)
> However, it would certainly be nice to have a way for setuptools-using
> packages to bootstrap the setuptools install -- and that includes
> setuptools itself. (My head is starting to spin now.)
> Hm. Unfortunately, it seems that the only other sane way to do this is
> to distribute Paste as an egg, and require people to use easy_install to
> install it, because then any dependency back to setuptools can be
> resolved properly once easy_install's automatic dependency installation
> is in place.
I wouldn't mind so much requiring easy_install to be installed -- if
that's the only firm prerequesite, that's okay. But a Paste checkout
gives you docs and examples and unit tests, which aren't part of an egg,
so Paste as installed by easy_install isn't complete.
One option would be if there was an option to install something the same
way you recommend using a development checkout -- don't create an egg,
just make sure the PackageName.egg-info directory is in place.
Incidentally, should there be a egg_setup command or something short of
creating an egg you won't use to create that special directory?)
Also, if I was just going to get rid of paster install (which is fine,
no big investment there), it does have the plugin-enabling code (where
plugins can register themselves with Paste). I'm not sure where that
would go; you could put the code into plugins themselves -- very
reasonable -- except how do they find the appropriate Paste
installation? I hate PYTHONPATH, and that's where this would lead.
> That doesn't help you much *now*, I realize. The big problem is that
> 'pkg_resources' really needs to be a singleton; there can't be multiple
> versions of it floating around at the same time, due to it containing
> global registries. Otherwise I'd tell you to just stick pkg_resources
> and easy_install in a package of your own and not worry about it.
Well, I'm wondering if it's okay to just download the setuptools egg and
put it on sys.path manually (obviously not using require() or anything
in setuptools). That's pretty easy to do. The only problem is when
they have a version of setuptools that is older than required -- if I
try to import it (not using require()) and it's too old, then I have to
delete it from sys.modules, which starts getting kind of long.
Especially since I can't write a library to do this ;)
I have thought in the past about writing a setup.py-builder, which might
make this more reasonable.
> Anyway, this is definitely a case for putting at least pkg_resources
> into the standard library as soon as it stabilizes sufficiently.
That might help. But only maybe. Having distutils in the stdlib isn't
making things any less complicated right now.
I almost think it makes sense to just have a hard line for packages that
use this stuff: if setuptools isn't installed (or is too old), then go
install it and start again. That way, assuming it is popular, it can
become kind of standard regardless of your Python version.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Distutils-SIG