On Tue, Aug 4, 2009 at 11:43 PM, Jim Fulton
Buildout will often reinstall setuptools, depending which version it thinks it needs. I'd expect this to defeat whatever you've done.
Distribute "installs" setuptools 0.6c9, so unless buildout tries to downgrade setuptools, it should not defeat it, Do you have a scenario in mind I can try ?
If distribute is truly a setuptools clone,
it's the very same code, besides the bug fixes we applied, like the svn 1.6 compatibility fix and stuff like that.
I suppose that the project name to use could be configurable in buildout. This would take some work, but probably not that much.
zc.buildout.Buildout class could be changed indeed, so methods like boostrap() don't harcode the setuptools distribution name anymore, but how would you handle the install_requires field in zc.buildout ? I mean, beside all the bootstrap, zc.buildout stills depends on the 'setuptools' dist, requiring Distribute to fake it's installed, to avoid an "install battle" where the last distribution installed wins. Or, the setup.py script could try to import pkg_resources and decide which value to put in install_requires depending on what is installed, (choosing setuptools by default if nothing is installed)
That seems cleaner and less brittle than hacking installed setuptools distributions.
Unfortunalety, even outside zc.buildout, I don't see any other solution than setting up a "fake" setuptools, to avoid changes in third party softwares, like their "install_requires" field. I see the 0.6 version of Distribute as a hack in any case, until Distribute 0.7 change the package/modules names, If anyone think about a better plan for the switch, speak up :) Tarek -- Tarek Ziadé | http://ziade.org