- Zope-Dev - Zope lists

zope.testrunner and nose count doctests differently
by Chris Withers 08 Nov '11

08 Nov '11

Hi All, I'm experimenting with using nose as an alternative to zope.testrunner so I can take advantage of the junit and cobertura compatible xml output offered. However, it appears that doctest counting is different between the two: $ bin/test -m testfixtures.tests.test_docs Running zope.testrunner.layer.UnitTests tests: Set up zope.testrunner.layer.UnitTests in 0.000 seconds. Ran 316 tests with 0 failures and 0 errors in 0.136 seconds. Tearing down left over layers: Tear down zope.testrunner.layer.UnitTests in 0.000 seconds. $ bin/nosetests testfixtures/tests/test_docs.py ................ ---------------------------------------------------------------------- Ran 16 tests in 0.134s Does anyone knows why this count is different? What code is counting differently? I'm paranoid that nose might not be running some tests that zope.testrunner is. If you want to take a look at the code, it's here: https://github.com/Simplistix/testfixtures zope.testrunner is used on the master branch, nose on the nose branch. Any help gratefully received! cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

7 10

Re: [Zope-dev] [TIP] zope.testrunner and nose count doctests differently
by Chris Withers 08 Nov '11

08 Nov '11

Hi All, On 07/11/2011 22:25, Michael Foord wrote: > On 07/11/2011 19:51, Mark Sienkiewicz wrote: >> On 11/07/11 12:53, Chris Withers wrote: >>> The only hiccup is that nose doesn't respect a test_suite function by >>> default, so I wrote a plugin to make it do the right thing: >>> >>> Nose people: any idea *why* nose doesn't respect this method? Mark has somewhat misdirected the thread here, either that or I've got in a muddle, anyway, the issue at hand is that nose ignores TestCase.countTestCases(). Any nose people know what that is? > unittest doesn't *require* you to write a test_suite either - the point > of test_suite is to allow you to *customize* the set of tests that are > collected automatically when a test module is loaded. So if you are > providing a test_suite it is because the default automatic collection > strategy isn't enough for you. This is true now, but I'm pretty sure when unittest was introduced, you had to provide a test_suite function for test discovery to work. Of course, that's the dim and distant past and so doesn't really matter. However, the fact that nose ignores a test_suite method is a bug, plain and simple ;-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

zope.schema and Python 3
by Brian Sutherland 08 Nov '11

08 Nov '11

I've managed to port zope.schema to Python 3.2 on a branch (jinty-python3). It gives up Python 2.5 compatibility and depends on six (http://packages.python.org/six/) Any objections to me merging this branch? -- Brian Sutherland

4 8

zope-tests - FAILED: 1, OK: 46
by Zope tests summarizer 08 Nov '11

08 Nov '11

This is the summary for test reports received on the zope-tests list between 2011-11-06 00:00:00 UTC and 2011-11-07 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [1] winbot / z3c.form_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -------------- [1] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-November/052312.html

2 1

New ZTK-Release?
by Michael Howitz 07 Nov '11

07 Nov '11

Hi all, after having the buildbots green again, I think it would be a good point in time for a series new ZTK releases: * 1.0.5 (yes, there are even on the 1.0 branch version updates), * 1.1.3, * 1.2c1 (a new release branch from the trunk) Who is in charge for the ZTK releases? Is there still the ZTK team? Yours sincerely, -- Michael Howitz · mh(a)gocept.com · software developer gocept gmbh & co. kg · Forsterstraße 29 · 06112 Halle (Saale) · Germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development

2 1

Re: [Zope-dev] zope-tests - FAILED: 3, OK: 45
by Tres Seaver 07 Nov '11

07 Nov '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/07/2011 08:11 AM, Stephan Richter wrote: > On Monday, November 07, 2011 07:32:04 AM Tres Seaver wrote: >>>> Same as it ever was: who was it again who feels responsible >>>> for maintenance on z3c.form? >>> >>> I am maintaining z3c.form, just not the Windows release, since >>> I have (a) no suitable setup and (b) really no interest to do >>> so. >> >> OK, cool. The test failure here doesn't appear to be related to >> Windows (I think Hanno pinned lxml to work around earlier >> failutres) >> >> http://winbot.zope.org/builders/z3c.form_py_265_32/builds/334/steps/test/log >> >> >> s/stdio > > Fixed. It turned out that this test pointed out a bug in Chameleon > that has now been fixed. So all I needed to do is remove the test. > :-) Easy enough. > > I applied the fix to trunk, which is where this test was failing > from, right? Correct. Thanks very much -- I think tomorrow we should see a completely green board for the first time in a looooong time. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk632YUACgkQ+gerLs4ltQ7EnQCggmPL/lTr/AKvZcL16Xv3Ca/N NtgAn01QCkCI4L6/kGwC5BKQIgEhhBO7 =2Kwk -----END PGP SIGNATURE-----

1 0

Re: [Zope-dev] zope-tests - FAILED: 3, OK: 45
by Tres Seaver 07 Nov '11

07 Nov '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/07/2011 07:24 AM, Stephan Richter wrote: > On Monday, November 07, 2011 07:08:20 AM Tres Seaver wrote: >>> [3] FAILED winbot / z3c.form_py_265_32 >>> >>> https://mail.zope.org/pipermail/zope-tests/2011-November/052265.ht >>> >>> ml >> Same as it ever was: who was it again who feels responsible for >> maintenance on z3c.form? > > I am maintaining z3c.form, just not the Windows release, since I > have (a) no suitable setup and (b) really no interest to do so. OK, cool. The test failure here doesn't appear to be related to Windows (I think Hanno pinned lxml to work around earlier failutres) http://winbot.zope.org/builders/z3c.form_py_265_32/builds/334/steps/test/lo… Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver(a)palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk63z8QACgkQ+gerLs4ltQ4vqwCdEdEaXMeX+z9v3VYI1vVCGxy7 4f8AoKaSbBe545xtg0VtLhgvg2iEzXat =bfYj -----END PGP SIGNATURE-----

1 0

zope-tests - FAILED: 3, OK: 45
by Zope tests summarizer 07 Nov '11

07 Nov '11

This is the summary for test reports received on the zope-tests list between 2011-11-05 00:00:00 UTC and 2011-11-06 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received ---------------- Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.7 64bit linux Bluebream / Python2.7.2 64bit linux [1] Total languishing bugs for zope2: 4 ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.7 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.5.5 Linux 64bit ZTK 1.1 / Python2.6.7 Linux 64bit ZTK 1.1 / Python2.7.2 Linux 64bit ZTK 1.1dev / Python2.5.5 Linux 64bit ZTK 1.1dev / Python2.6.7 Linux 64bit [2] ZTK 1.1dev / Python2.7.2 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 [3] winbot / z3c.form_py_265_32 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -------------- [1] FAILED Total languishing bugs for zope2: 4 https://mail.zope.org/pipermail/zope-tests/2011-November/052262.html [2] FAILED ZTK 1.1dev / Python2.7.2 Linux 64bit https://mail.zope.org/pipermail/zope-tests/2011-November/052267.html [3] FAILED winbot / z3c.form_py_265_32 https://mail.zope.org/pipermail/zope-tests/2011-November/052265.html

2 1

ZEO client cache not working properly with beforestorage
by Malthe Borch 07 Nov '11

07 Nov '11

If I set my beforestorage to a reasonably current time, e.g. "now", I expect to get reasonably good performance from a ZEO client cache. Instead, I find that beforestorage: 1) asks the cache to ``loadBefore``; 2) but that method only looks for "noncurrent" entries; 3) meanwhile, my cache only has "current" records. I'm not sure if the problem is that the cache shouldn't be setting the loaded oids as "current", or if the ``loadBefore`` method should also accept (some) "current" entries. \malthe

2 4

Zope 4 - San Francisco sprint and beyond
by Hanno Schlichting 07 Nov '11

07 Nov '11

Hi. A couple of us came together before the Plone conference to work on various Zope related topics. We worked on the following areas: - storing parent pointers (elro, davisagli): we have a branch of Zope that changes OFS to store parent pointers and fixed the issues that arose in copy/cut/paste and zexp export code. There's an issue remaining with Acquisition, where we lost some protection against cycle protection - I continue working on this. - catalog using intids (rossp): we have branches of Zope, ZCatalog and CMF which change the catalog to use intids as their internal uid and rid. This needs more testing, but looks very promising. Currently it uses plone.app.intid / five.intid to maintain an intid to physical path mapping. Once the parent pointer work is stable, we can stop doing this and load objects directly from the database connection - Chameleon (chaoflow): Florian worked on making Zope use Chameleon by default. This works for the most parts, but there's some problems left in tests, as Chameleon wants an utility to be registered but a lot of tests in Zope and CMF don't use ZCML test layers. - Traversal simplification: Mikko worked on researching traversal and options to simplify it. The first idea was to unify some of the code used for URL, path and path expression traversal to bring those more in line. Not sure how far he got ;) - WebOb (garbas): Rok worked on bringing in WebOb as an underpinning for the request/response objects and making both API's available at the same time. I think the request is done and a good deal of the response works. Doing this means we can deprecate parts of the old request API and encourage the use of the more standard WebOb API. - WSGI (matthewwilkes, hannosch): We fixed the bugs that had been reported about using the current WSGI support (mod_wsgi problems, forced dependency on repoze.who) on trunk and the 2.13 branch. Afterwards Matthew continued on a branch to remove the ZServer/medusa from Zope and leave only the WSGI publisher in place. We had a bunch of other ideas on what to do, like allowing Unicode ids in OFS, working on security and similar large topics. I hope I haven't forgotten anyone. Most of the code currently lives in branches or forks on https://github.com/zopefoundation. We haven't figured out yet how to proceed with that. In terms of copyright all committers to the GitHub repository have signed Zope contributor agreements already, so there's no imminent legal problem. Which of these branches should make it into Zope and for which release is completely open and is going to be up for discussion. On a personal note, I won't be available as the release manager for the next Zope 4 release - as originally outlined in my mail from 2010 (https://mail.zope.org/pipermail/zope-dev/2010-March/039880.html) I'll continue to take care of the maintenance releases for the 2.12 and 2.13 series. At least unless someone else shows an interest in picking up this work. Should there be anyone interested in this position, speak up on this mailing list. Once someone has been found, I'll make sure the person gets documentation and access to all relevant resources. Hanno

2 1