Paul Winkler wrote:
Posting this here because the code in question lives in zope.testing...
After accidentally nuking my mxODBCZopeDA installation simply by running
"bin/zopectl test" in a zope 2.9 instance, I quickly concluded:
There is no "bug". testrunner.py is behaving exactly as designed. Stale
bytecode causes "spurious test failures due to finding compiled modules
where source modules have been deleted." Therefore, we should delete it
But this conflicts with third parties being able to deliver bytecode
instead of source, which is a standard python feature (if not common in
the zope world). Since we can't tell the difference between "stale" and
"we never had source in the first place", deleting bytecode is arguably
surprising and overly invasive.
I guess it comes down to choosing the lesser of two evils. Which is
worse? Confusing test errors caused by stale bytecode, or a test run
having the power to break your instance with the default options?
I don't see a third path.
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
Zope3-dev mailing list