I finally discovered zope.release (and by "discovered" I mean Stephan Richter told me about it on IRC, again, but this time I had the time to take a look). It has a script that generates a buildout of all the KGS packages so you could run the tests on all of them:
svn co svn+ssh://svn.zope.org/repos/main/zope.release/branches/3.4 zope.release cd zope.release buildout bin/generate-buildout cd test buildout
For some reason, the test script tries to run all the tests found in my /usr/lib/python2.5/site-packages, some of which then fail.
vi bin/test remove site-packages
bin/test -pvc
I see 9 failures and 4 errors on my system (Python 2.5 on 32-bit Linux):
* z3c.coverage 1.1.1 has a nondeterministic test (assumes the order of the names returned by os.listdir()). This has been fixed in SVN, but nobody has made a 1.1.2 release and updated the KGS. I don't have PyPI rights to release z3c.coverage.
* z3c.form 1.8.0 is not compatible with Python 2.5 (assumes OverflowWarning)
* z3c.rml 0.7.3 tests fail to find random TTF font files and fail.
* zc.zope3recipes 0.6.1 is trying to get a distribution for setuptools, recursively, until it gets a stack overflow error
* zope.server 3.4.2 is very unhappy about some bad file descriptors
* the test runner keels over at the end of the unit test run, with AttributeError: 'module' object has no attribute 'DemoLayer'
If I then continue by skipping the unit tests
bin/test -pvc -f
all the tests in layers pass.
I have interest in fixing these errors, especially the test runner one (because it's important), and the z3c.coverage one (because it's easy). I don't know if Python 2.5 compatibility is important for the 3.4 KGS, but the z3c.form problem seems to be easy to fix.
I don't believe I have the expertise to handle the zc.zope3recipes recursive setuptools failure. Although it looks like it could provide me with a few hours of entertaining debugging, I've no confidence I can fix it. The zope.server multi-threaded bad file descriptor errors also seem tricky.
A lot of tests like to spew random output to stdout/stderr, which makes interpreting the test output harder (and probably breaking the test runner if it has to run any of those tests in a subprocess, e.g. if you want to run those tests in parallel). A crusade to clean that up is out of scope for 3.4, IMHO.
I think I'll run the test suite again on a 64-bit Linux machine, for extra fun. And maybe do that for Python 2.4 as well.
Marius Gedminas
Marius Gedminas wrote:
I think I'll run the test suite again on a 64-bit Linux machine, for extra fun. And maybe do that for Python 2.4 as well.
zope.proxy and related modules failed badly under 64 bit Python 2.5 until I fixed the C code on the trunk 2 weeks ago, however, I don't think my changes landed in the KGS. I also fixed broken tests. Should I backport my changes? I don't know whether a release is planned soon.
Shane
Shane Hathaway wrote:
Marius Gedminas wrote:
I think I'll run the test suite again on a 64-bit Linux machine, for extra fun. And maybe do that for Python 2.4 as well.
zope.proxy and related modules failed badly under 64 bit Python 2.5 until I fixed the C code on the trunk 2 weeks ago, however, I don't think my changes landed in the KGS. I also fixed broken tests. Should I backport my changes? I don't know whether a release is planned soon.
Hey Shane,
thanks for those fixes! I've just made the necessary backports and tagged the following releases:
zope.proxy 3.4.2 zope.security 3.4.1 zope.security 3.5.2 zope.app.container 3.5.5
I haven't uploaded them to PyPI yet because a) I don't have the rights to all of them and b) they have extension modules which means we should simultaneously release Win32 binaries (which I can't). I've therefore CC'ed Jim, hoping that he could upload the sdist tarballs and the binary eggs for Windows.
Jim?
Thanks, Philipp
Philipp von Weitershausen wrote:
thanks for those fixes! I've just made the necessary backports and tagged the following releases:
zope.proxy 3.4.2 zope.security 3.4.1 zope.security 3.5.2 zope.app.container 3.5.5
I see that the backporting and tagging was a fair amount of work! Thanks for taking that on.
Shane
On Sun, Jul 27, 2008 at 02:18:23PM +0300, Marius Gedminas wrote:
I finally discovered zope.release (and by "discovered" I mean Stephan Richter told me about it on IRC, again, but this time I had the time to take a look). It has a script that generates a buildout of all the KGS packages so you could run the tests on all of them:
svn co svn+ssh://svn.zope.org/repos/main/zope.release/branches/3.4 zope.release cd zope.release buildout bin/generate-buildout cd test buildout
For some reason, the test script tries to run all the tests found in my /usr/lib/python2.5/site-packages, some of which then fail.
vi bin/test remove site-packages
This also happens if I use python2.4 bootstrap.py && bin/buildout instead of using my system-wide easy_installed zc.builbout.
I see 9 failures and 4 errors on my system (Python 2.5 on 32-bit Linux):
And today I see 13 failures and 5 errors on Python 2.5 on 64-bit Linux, but only 9 failures and 3 errors on Python 2.4 on the same 64-bit Linux.
- the test runner keels over at the end of the unit test run, with AttributeError: 'module' object has no attribute 'DemoLayer'
This is caused by z3c.skin.pagelet 1.0.2, which has a z3c/skin/pagelet/testing.py with
TestLayer = ZCMLLayer( os.path.join(os.path.split(__file__)[0], 'ftesting.zcml'), __name__, 'DemoLayer', allow_teardown=True)
The test runner should verify this during import time and complain early, instead of crashing in the middle of the run.
I also don't know why this doesn't always trigger the crash. The test runner has some sort of a layer cache, that might explain it.
I think I'll run the test suite again on a 64-bit Linux machine, for extra fun. And maybe do that for Python 2.4 as well.
Did that.
Marius Gedminas
-
Marius Gedminas -
Philipp von Weitershausen -
Shane Hathaway