- Zope-Dev - Zope lists

Another possible zope.testing deprecation...
by Lennart Regebro 29 Apr '10

29 Apr '10

There is a zope.testing.exceptions module. It contains only one exception: DocTestFailureException, which is used by the testrunner, and as far as I can tell, only the testrunner. So we should probably move that one over to zope.testrunner as well. Which means deprecating it in zope.testing, of course. Anyone see any problems with this? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

2 2

I would like to have some releases
by Lennart Regebro 29 Apr '10

29 Apr '10

I would like to have the following packages released, or the permissions to release them myself. This is all in preparation for Python 3 support. zope.interface zope.events zope.exceptions zope.testing zc.recipe.testrunner The releases of zope.interface, zope.events and zope.exceptions introduce Python 3 compatibility. The release of zope.testing deprecates zope.testing.testrunner for zope.testrunner (just released). zc.recipe.testrunner uses zope.testrunner instead of zope.testing.testrunner. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64

3 6

version pinning on tags
by Adam GROSZER 29 Apr '10

29 Apr '10

Hello, I found while trying to get the KGS 3.4.1 together that MISSING versions on tags/previous versions are BAD. The problem is that if you work with the trunk you test the package against (usually) the current versions. If you later get back to a package for a bugfix or whatever, it's a pain to get the tests running again because the dependent package versions shifted. Right now the only chance is to guess versions or KGS's. I'd say we should nail the package versions on (at least) tags. Either to a KGS, or drop a versions.cfg into the package. The recipe buildout.dumppickedversions would be handy. Opinions? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: All mankind is divided into three classes: those who are immovable, those who are movable; and those who move. - Benjamin Franklin

5 8

ZTK & Friends Bug Day 19th May 2010
by Charlie Clark 29 Apr '10

29 Apr '10

Hi, It was agreed yesterday that "little and often" bug days are a good idea. The next one will be 19th May 2010. Whether working with others together or just staying in touch on IRC the idea is to try and work on outstanding bugs. It's worth noting that many bug reports come with patches that just need reviewing, testing and then maybe fixing and committing or even rejecting. And you don't have to spend all day fixing bugs. There is introductory documentation on what you need in order to take part: http://docs.zope.org/developer/ Baiju kindly offered to set up Wiki for those planning to take part so everyone has an idea of who'll be taking part and what they're planning to work on. Knowing other people are working specifically on bug fixes makes it easier when asking for help. Charlie

2 1

releasing KGS
by Adam GROSZER 28 Apr '10

28 Apr '10

Hello Stephan, Looking at svn://svn.zope.org/repos/main/zope.release/branches/3.4/README.txt At 6.) you do a /bin/upload, it's all I need to do the release? How does the http://download.zope.org/zope3.4/3.4.0/versions.cfg get created? There are some scripts in bin, but I'd rather not make a mistake. bin/upload does somewhere an scp to download.zope.org, where I don't have permission. Whom to ask for permission or to do the upload? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Hypocrites in the Church? Yes, and in the lodge and at the home. Don't hunt through the Church for a hypocrite. Go home and look in the mirror. Hypocrites? Yes. See that you make the number one less. - Billy Sunday

2 1

bugday followup for KGS 3.4.1
by Adam GROSZER 28 Apr '10

28 Apr '10

Hello, Did anyone do a backport that could be interesting for the KGS 3.4.1? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Chinese saying: "He who speak with forked tongue, not need chopsticks."

1 0

Zope Tests: 10 OK, 6 Failed
by Zope Tests Summarizer 28 Apr '10

28 Apr '10

Summary of messages to the zope-tests list. Period Tue Apr 27 12:00:00 2010 UTC to Wed Apr 28 12:00:00 2010 UTC. There were 16 messages: 6 from Zope Tests, 9 from ccomb at free.fr, 1 from ct at gocept.com. Test failures ------------- Subject: FAILED: Repository policy check found errors in 670 projects From: ct at gocept.com Date: Tue Apr 27 21:21:15 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014145.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 32bit From: ccomb at free.fr Date: Tue Apr 27 23:14:01 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014157.html Subject: FAILED : ZTK 1.0dev / Python2.5.2 Linux 32bit From: ccomb at free.fr Date: Tue Apr 27 23:14:02 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014156.html Subject: FAILED : ZTK 1.0dev / Python2.6.4 Linux 32bit From: ccomb at free.fr Date: Tue Apr 27 23:14:11 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014158.html Subject: FAILED : Zope 3.4.1 KGS / Python2.4.6 32bit linux From: ccomb at free.fr Date: Wed Apr 28 00:22:02 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014159.html Subject: FAILED : Zope 3.4.1 KGS / Python2.5.2 32bit linux From: ccomb at free.fr Date: Wed Apr 28 00:44:56 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014160.html Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue Apr 27 21:31:17 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014146.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue Apr 27 21:33:17 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014147.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Tue Apr 27 21:35:17 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014148.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Apr 27 21:37:17 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014149.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Tue Apr 27 21:39:17 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014150.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Tue Apr 27 21:41:17 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014151.html Subject: OK : BlueBream template / Python2.4.6 32bit linux From: ccomb at free.fr Date: Tue Apr 27 22:00:46 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014152.html Subject: OK : BlueBream template / Python2.5.2 32bit linux From: ccomb at free.fr Date: Tue Apr 27 22:00:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014155.html Subject: OK : BlueBream template / Python2.7b1 32bit linux From: ccomb at free.fr Date: Tue Apr 27 22:00:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014154.html Subject: OK : BlueBream template / Python2.6.4 32bit linux From: ccomb at free.fr Date: Tue Apr 27 22:00:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014153.html

1 0

zope.testing 4.0.0 coming up.
by Lennart Regebro 27 Apr '10

27 Apr '10

I've been working on zope.tetsing lately. The main impetus behind this is Python 3 compatibility, but also general cleanup. This work was discussed on #zope bu Jim Fulton, Stephan Richter, Charlie Clark and me. The conclusion was to release a backwards incompatible zope.testing 4.0.0. The backwards incompatibility is the following: 1. zope.testing.testrunner is now in it's own module, zope.testrunner. I will add a deprecation warning to trunk first, and we'll have to release a new zope.testing 3.x version, then 4.0.0 can be merged. 2. zope.testing.doctest will be dropped. There is already a deprecation warning about this. zope.testing 4.0.0 will support Python 3. Questions? :) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64

3 3

RFC: Proposed new style for documenting and testing ZTK packages
by Tres Seaver 27 Apr '10

27 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This kind of goes with Lennart's frustration about trying to port the ZTK packages, or a core subset, to Python 3. I would like to see the ZTK packages have really excellent documentation, as well as 100% test coverage. I think we need to look at refactoring how the testing story is done to get both needs satisfied: trying to achieve both with a single set of doctests is pretty near impossible: - - Testing setup and teardown code obscures the narrative flow / intent of the documentation. - - Edge case testing *really* obscures the same. - - Test coverage suffers, because it is hard to write edge-case tests in doctest. - - Porting the doctests where people have tried to juggle both goals across Python versions is a mess. The refactoring I would like to see happen is to move the main narrative documentation into a separate, Sphinx-driven 'docs' directory in each ZTK package. As part of this move, we can start adding some of the really nice Sphinx features (cross references, indexing, auto-generation of API reference information, etc.). We can still leave the "main line" of the code illustrated using doctest-style blocks: Sphinx has nice support for testing those blocks *while building the docs*. At the end of this part of the change, each package would have a much improved documentation set, with tested examples. At the end of the process, we would be able to put the docs for each package into an "intersphinx" tree underneath the main ZTK docs, which could serve as the gateway into them. The trickier testing bits we would re-write as super thorough, no shortcuts-taken unit tests: one testcase class per class (or API function) under test, at least one method per class-under-test method, with more preferred to get all code paths / preconditions covered. The goal here would be to comment out the doctests from the test_suites and get the code to 100% coverage using pure unit tests. Meanwhile, the doctests would be refactored into the Sphinx documentation, losing all the bits which obscure their intent as documentation. I would say that the risks here are slight, given that aiming for 100% test coverage is likely to catch any oversights made during porting to the new style. The amount of work for any given package is fairly-well contained, I think: most of the effort will be in reverse-engineering the intent of the "edge-case" tests. I made a sketch at what these changes would look for the zope.event package like on a branch in Subversion: http://svn.zope.org/zope.event/branches/tseaver-new_style_docs I select zope.event largely because it is small enough that the scope of the structural changes wouldn't be lost in the diffs for the actual tests (and also because I didn't want to do the work for a bigger package before getting feedback). The rendered docs from that branch are here: http://palladion.com/static/zope.event-docs/ I pushed the bzr branch to Launchpad, to let you see the kinds of changes I made to get there (our viewcvs story is not nearly as easy to review as the Launchpad changeset view): https://code.launchpad.net/~tseaver/zope.event/new_style_docs I am attaching an annotated diff for those who would prefer to see the changes in that format. I would say that this cleanup effort should start at the "bottom" layers of the ZTK, dependency-wise (zope.interface, zope.component, etc.) and move "upwards" (in the depenency sense) over time. Thoughts? 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvJEakACgkQ+gerLs4ltQ6X/wCgueT8RD10bKrM4OInF0sIj/Tk rs4AnAiQlBWZoHd35ti0tPlae/JsVgvC =K8N0 -----END PGP SIGNATURE-----

15 37

pypi access to zope.browserresource, zope.browsermenu
by Martijn Faassen 27 Apr '10

27 Apr '10

Hi there, Could someone give me and Hanno pypi access to zope.browserresource and zope.browsermenu? Our pypi usernames are: faassen hannosch Regards, Martijn

3 4