>> This worked (which is what I normally do): [build_ext -i]

> It did for me too. I guess the crucial difference was doing build_ext
> instead of just build.


> 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:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to