At 10:41 PM 4/29/2007 -0500, Ian Bicking wrote:
Phillip J. Eby 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
At 04:04 PM 2/20/2007 -0600, Ian Bicking wrote: 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.