[Tim] ... >> This worked (which is what I normally do): [build_ext -i]
[Thomas] > It did for me too. I guess the crucial difference was doing build_ext > instead of just build. Yes. > Maybe someone with more distutils clue could say something about it; if > my guess is right, README.txt should be changed. It's more likely due to people fiddling with zpkg. "setup.py build" _had_ worked fine for running the tests for years, and I know it still worked fine a few months ago. But I don't normally do that, so didn't notice when it broke. It's not due to changes in ZODB code (no relevant changes have been made there -- or at least none that I made ;-)). For whatever reason, looks like "setup.py build" in ZODB simply ignores the existence of ZODB's zope/testing directory now (but doesn't ignore ZODB's other zope/* directories ...). ... >> I don't know what +1 means on other lists, but on this list it means >> "that's such a good idea I'm going to devote my life to implementing it, >> and I promise to finish it before this time next week" -- thanks ;-) > Normalization of votes should definitely be standardized across lists. I was pulling your leg -- +1 means the same thing here as elsewhere ("strong yes, to the extent that I'll least argue in favor of it"). > But then, what does "implementing a deprecation" mean? If it's just > adding a deprecation warning, I should be able to make it in time ;o) It means adding the warning, documenting the deprecation in NEWS.txt, adding a test to ensure that the deprecation warning is raised when appropriate, and possibly a bunch of tedious hair to suppress the new warning(s) while the tests that exercise the now-deprecated feature are running (while deprecated, it's still supported until it goes away, so the tests for it still need to run). _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev