Re: [Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
Hi Paul, Paul Winkler wrote: 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. It's arguably surprising and overly annoying not to ship the source, but I guess that's eGenix' choice... 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. I do ;-) What if we let the test runner suck a list of .pyc files not to delete from somewhere? Where should we suck this list from? cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
On Tue, Oct 10, 2006 at 08:13:23PM -0400, Jim Fulton wrote: 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 by default. 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. ideas? opinions? See: http://www.python.org/pypi/zope.testing#running-without-source-code Thanks for the pointer. AFAICT the current docs confirm my understanding. --usecompiled would be useful if I wanted to run tests in a package for which I didn't have source. That's not the case here. All I need is -k, --keepbytecode. I think the current default behavior sucks, but I think changing it would just suck differently :-( -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
Paul Winkler wrote: On Tue, Oct 10, 2006 at 08:13:23PM -0400, Jim Fulton wrote: [...] See: http://www.python.org/pypi/zope.testing#running-without-source-code Thanks for the pointer. AFAICT the current docs confirm my understanding. --usecompiled would be useful if I wanted to run tests in a package for which I didn't have source. That's not the case here. All I need is -k, --keepbytecode. I think the current default behavior sucks, but I think changing it would just suck differently :-( The real problem as you noted in your original message is that there's no way to distinguish between a pyc file that is only intended to be used as a cache of bytecode for a py file, and a pyc file that is intended to be used standalone. If by default pyc files were created with a flag that indicated must have corresponding .py file, and the python interpreter refused to use such a pyc file if the corresponding py wasn't present, then there'd be no problem. People distributing pyc files without source could instruct compile_all or distutils or whatever to set the flag the other way. However, given the current situation, I think the current default is the safest. The surprise you get when a pyc is used that shouldn't have been is typically nastier (and more likely to happen) than the surprise caused by a pyc-only directory being cleaned out. -Andrew. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
Previously Andrew Bennetts wrote: The real problem as you noted in your original message is that there's no way to distinguish between a pyc file that is only intended to be used as a cache of bytecode for a py file, and a pyc file that is intended to be used standalone. Isn't the existing or non-existing of a corresponding .py file a good indication? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
Wichert Akkerman wrote: Previously Andrew Bennetts wrote: The real problem as you noted in your original message is that there's no way to distinguish between a pyc file that is only intended to be used as a cache of bytecode for a py file, and a pyc file that is intended to be used standalone. Isn't the existing or non-existing of a corresponding .py file a good indication? No, because you may have intended to remove the module. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
On Wed, Oct 11, 2006 at 11:43:13PM +0200, Wichert Akkerman wrote: Previously Andrew Bennetts wrote: The real problem as you noted in your original message is that there's no way to distinguish between a pyc file that is only intended to be used as a cache of bytecode for a py file, and a pyc file that is intended to be used standalone. Isn't the existing or non-existing of a corresponding .py file a good indication? No. It means one of two things, if you read the thread carefully. -- Paul Winkler http://www.slinkp.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.testing.testrunner: issue with remove_stale_bytecode
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 by default. 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. ideas? opinions? See: http://www.python.org/pypi/zope.testing#running-without-source-code Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
