[Distutils] workingenv/setuptools compatibility

Ian Bicking ianb at colorstudy.com
Mon Apr 30 05:41:40 CEST 2007


Phillip J. Eby wrote:
> At 04:04 PM 2/20/2007 -0600, Ian Bicking wrote:
>> Hi again.  I mentioned this a long time ago, but I'd like to talk about
>> it again: I'd really like to remove workingenv's monkeypatching of
>> setuptools.
> 
> Then remove it.  :)
> 
> You can trivially replace any setuptools built-in commands by simply 
> ensuring that you have corresponding 'distutils.commands' entry points 
> in the working set ahead of setuptools.  An easy way to do this in 
> workingenv would be to place your own egg in the easy-install.pth, and 
> removing setuptools' egg from there (leaving it in setuptools.pth).
> 
> This will then let you override the 'easy_install' and 'develop' 
> commands, to do whatever you want them to.

I was getting ready to start this, and then I realized it won't actually 
fix the problem I'm having.  workingenv works fine until, for some 
reason, easy-install.pth changes, setuptools is reinstalled, or 
something along those lines happens.  Then my monkeypatch breaks.  I 
fear that relying on my package to be above setuptools in 
easy-install.pth might be just as fragile.  Though perhaps if I put it 
in early-install.pth or something like that it would stay above setuptools?

> The only pieces this won't affect are the way setup_requires and 
> tests_require get handled (as they use direct imports from 
> setuptools.commands.easy_install) and the way 
> --single-version-externally-managed installs get their scripts generated 
> (which also uses direct imports).
> 
> However, if I understand correctly, you don't need either of these pieces.
> 
> Anyway, to do all this, you will need to have an egg that lists entry 
> points for 'easy_install' and 'develop' under the 'distutils.commands' 
> group.
> 
> (Actually, you might want to include an entry point for 'install' as 
> well, and override the do_egg_install method, which currently imports 
> easy_install directly instead of using 
> self.distribution.get_command_class('easy_install').  I'll fix that in 
> 0.6c6.)

Did these fixes get in, or should I look for other things I'd have to 
replace/subclass?

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
             | Write code, do good | http://topp.openplans.org/careers


More information about the Distutils-SIG mailing list