workingenv/setuptools compatibility
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. There's still just two things: * Removing easy_install's check of site.py (easy_install.install_site_py). * Changing the way scripts are created (using python -S and then changing the path). An option I could put in distutils.cfg for changing script creation would work great (since workingenv installs its own distutils.cfg). Maybe something that points to a function, and that function is passed the normal script text and then modifies it. Or just wraps get_script_header's text (that's what I'm currently doing). For setuptools' site.py, it would be nice if I could put a bit of text in there that indicates that it does everything setuptools' site.py does (at least as much as I choose to do -- no finding the system site.py in my case). Maybe something like __setuptools_setup_version__ = '0.6c6', or 'setuptools_site_py_hash = "xxxxx"', where that's an md5 hash of the setuptools' site.py that it was based on. Or something. This would substantially reduce the amount of annoying hacks in workingenv. And the script stuff would be useful in zc.buildout as well. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org
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. 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.)
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@colorstudy.com | http://blog.ianbicking.org | Write code, do good | http://topp.openplans.org/careers
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.
participants (2)
-
Ian Bicking -
Phillip J. Eby