Merge lp:~gary/zc.buildout/python-support-10 into lp:~gary/zc.buildout/python-support
Status: | Merged |
---|---|
Merged at revision: | not available |
Proposed branch: | lp:~gary/zc.buildout/python-support-10 |
Merge into: | lp:~gary/zc.buildout/python-support |
Diff against target: |
494 lines (+136/-33) 11 files modified
CHANGES.txt (+14/-2) bootstrap/bootstrap.py (+1/-1) dev.py (+44/-7) src/zc/buildout/buildout.py (+6/-1) src/zc/buildout/buildout.txt (+1/-0) src/zc/buildout/easy_install.py (+6/-1) src/zc/buildout/easy_install.txt (+6/-1) src/zc/buildout/tests.py (+42/-12) src/zc/buildout/update.txt (+3/-2) z3c.recipe.scripts_/src/z3c/recipe/scripts/tests.py (+3/-2) zc.recipe.egg_/src/zc/recipe/egg/tests.py (+10/-4) |
To merge this branch: | bzr merge lp:~gary/zc.buildout/python-support-10 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Francis J. Lacoste (community) | Approve | ||
Review via email: mp+24387@code.launchpad.net |
Description of the change
This branch fixes the two linked bugs. The fixes are in r548 (http://
Bug 564680 was addressed in line 1491 of easy_install.py in r548. The problem was that we were getting Distribute's custom site.py when we were making our site.py customization, and we wanted the real Python site.py. The solution was to insert a -S to the Python invocation so that site-packages were not included when we found site.py. This was a good general thing to do.
Bug 568486 was addressed in line 1614 of easy_install.py in r548. The problem was that Distribute was using a custom mechanism to know where to insert its eggs. I supplied the necessary value for the mechanism in the generated scripts (sys.__egginsert).
The revision also includes a fix for a pre-existing bug (from zc.buildout trunk) that I discovered when I tried (and succeeded) to have Launchpad use Distribute in buildout. This is line 807-808 of easy_install.py in r548. Using Distribute with the ``allow-
Figuring out a way to test all this took me awhile, but I eventually hit on the idea of making it possible to run all tests with Distribute. I changed dev.py to support this. This tests the bugs I found--if you take out my changes from r548, things fail.
Therefore, to fully test buildout now you need to run the test suite six times: the product of the setuptools implementation, Setuptools or Distribute, and the Python version, 2.4, 2.5, and 2.6. I did the six tests with this branch. Everything works except Distribute + Python 2.4. I'm simply not interested enough in that combination to pursue it.
Getting the tests to pass with Distribute took some doing, and a lot of RENormalizing. I'm going to give a quick overview of these changes in hopes it helps understanding.
A lot of the changes to the RENormalizing checkers normalize "distribute" to "setuptools" in the doctest output. That very simple normalization is there a few times for various tests (``(re.
The RENormalizing change that bothered me the most was this one, which is also repeated for a few tests: ``(re.compile('\- demoneeded'), 'd demoneeded')``. I was trying to figure out why buildout with Distribute was unzipping many more eggs. Eventually I encountered this code in Distribute:
def should_unzip(self, dist):
if self.zip_ok is not None:
return not self.zip_ok
if dist.has_
return True
if not dist.has_
return True
return True
That made me laugh, but in any case, it pretty much always returns True. That's Distribute's policy (as opposed to Setuptools, where the last line would have been "return False"), and it is affecting the demoneeded package, so I kept it.
The test for upgrading setuptools was a bit trickier than simply RENormalizing because I had to create Distribute eggs instead of setuptools eggs, and make buildout support ``distribute-
That's pretty much it. Once this is approved, I'll merge it with my python-support branch, and then merge it with zc.buildout trunk and make a 1.5.0 beta 1 release.
Thanks!
All makes sense.