[Distutils] workingenv/setuptools compatibility

[Phillip J. Eby]

At 10:41 PM 4/29/2007 -0500, Ian Bicking wrote:
>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?

As long as you install it the way eggs get installed (i.e., with the Python 
code in the .pth file to push it to the head and track it), yes.


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

No, they haven't gone in yet.  Anything that directly imports easy_install 
(or anything else you're overriding) needs to be changed to use the 
distribution object's get_command_class('easy_install') instead.