Re: [Zope-dev] KGS 3.4.1 versions
Hi > Betreff: Re: [Zope-dev] KGS 3.4.1 versions > > Adam GROSZER a écrit : > > Hello, > > > > There is a sheet with versions for KGS 3.4.1 > > > http://spreadsheets.google.com/pub?key=tUE5Q72d4Kg1FXaacCA3EKQ&output= > > html > > > > Anyone for/against those versions? > > > > The open questions that remain: > > * What about pytz 2010g? > > * Which lxml version to take? 1.3.6? > > * What about zope.app.container 3.6.2? > > * Would be nice to have zope.testbrowser 3.5.1 > > > > Comments are welcome. > > > > z3c.layer has a major security issue, because of trusted > traversing adapters that removes the security proxy > everywhere. yes and no, only miss use could end in security issues It's not really a security issue, it's the only concept which allows to use nested sites with more then one IAuthentication utility and allows to authenticate on objects behind the first site. But since this was such a rare use case, we decided to split the package in different packages which also supports a non trusted setup. This makes the packages more general usable without to run into security issues based on trusted confirgurations where non trusted is needed. > This package has been retired and splitted into > its 3 subpackages : > > z3c.layer.minimal > z3c.layer.pagelet Both package above should not use trusted traverser > z3c.layer.trusted This package should still use trusted traverser > > There is no problem upgrading to branch 1.0 of these > packages, as they don't have any significant changes, > excepted the splitting. However: > > z3c.layer.pagelet should be in version 1.0.2. Nothing below. > z3c.layer.minimal has no corrected 1.0 branch. A new > maintenance release 1.0.2 of this package should be released. > z3c.layer.trusted is OK, since this is trusted in purpose. (I think) Yes Regards Roger Ineichen > Christophe > ___ > Zope-Dev maillist - Zope-Dev@zope.org > https://mail.zope.org/mailman/listinfo/zope-dev > ** No cross posts or HTML encoding! ** (Related lists - > https://mail.zope.org/mailman/listinfo/zope-announce > https://mail.zope.org/mailman/listinfo/zope ) > ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 10 OK, 4 Failed
Summary of messages to the zope-tests list. Period Thu Apr 15 12:00:00 2010 UTC to Fri Apr 16 12:00:00 2010 UTC. There were 14 messages: 6 from Zope Tests, 7 from ccomb at free.fr, 1 from ct at gocept.com. Test failures - Subject: FAILED: Repository policy check found errors in 668 projects From: ct at gocept.com Date: Thu Apr 15 21:15:22 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013971.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 32bit From: ccomb at free.fr Date: Thu Apr 15 23:56:35 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013982.html Subject: FAILED : ZTK 1.0dev / Python2.5.2 Linux 32bit From: ccomb at free.fr Date: Thu Apr 15 23:57:55 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013983.html Subject: FAILED : ZTK 1.0dev / Python2.6.4 Linux 32bit From: ccomb at free.fr Date: Thu Apr 15 23:58:01 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013984.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 15 21:29:25 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013972.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Thu Apr 15 21:31:26 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013973.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Thu Apr 15 21:33:26 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013974.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Apr 15 21:35:26 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013975.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Thu Apr 15 21:37:26 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013976.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Thu Apr 15 21:39:26 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013977.html Subject: OK : BlueBream template / Python2.4.6 32bit linux From: ccomb at free.fr Date: Thu Apr 15 22:00:45 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013979.html Subject: OK : BlueBream template / Python2.5.2 32bit linux From: ccomb at free.fr Date: Thu Apr 15 22:00:45 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013978.html Subject: OK : BlueBream template / Python2.6.4 32bit linux From: ccomb at free.fr Date: Thu Apr 15 22:00:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013981.html Subject: OK : BlueBream template / Python2.7b1 32bit linux From: ccomb at free.fr Date: Thu Apr 15 22:00:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/013980.html ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS 3.4.1 versions
On Thu, Apr 15, 2010 at 12:29, Adam GROSZER wrote: > The open questions that remain: > * What about pytz 2010g? I'm not sure it makes sense fixing it to a particular version at all, as you might want timezone updates separately. Just sayin'. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] KGS 3.4.1 versions
Hello, I think it's about having a known set of versions for the tests. Not that test run picks up some newer versions and the tests suddenly fail. On Fri, Apr 16, 2010 at 2:21 PM, Lennart Regebro wrote: > On Thu, Apr 15, 2010 at 12:29, Adam GROSZER wrote: >> The open questions that remain: >> * What about pytz 2010g? > > I'm not sure it makes sense fixing it to a particular version at all, > as you might want timezone updates separately. Just sayin'. :) > > -- > Lennart Regebro: Python, Zope, Plone, Grok > http://regebro.wordpress.com/ > +33 661 58 14 64 > -- Best regards, Adam ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Minutes from this weeks meeting
On Thu, Apr 15, 2010 at 11:31:32PM +0200, Christian Theune wrote: > On 04/15/2010 11:27 PM, Wichert Akkerman wrote: > > On 2010-4-15 17:59, Christian Theune wrote: > >> Hi, > >> > >> here's the minutes. As I've been adventurous, I'll add a few comments: > >> > >> * I've started diving into the matter of how to manage items that we > >> park/defer/postpone/wait for and thus started using an online system. > >> (The only one I was able to find anyway.) > >> > >> * The output is a PDF which is currently a bit messy as I wanted to get > >> rid of my text files that had the open issues sitting in there and > >> thus had to add all of them to our agenda on Tuesday and then defer > >> them. I think next week will become less noisy. > > > > Will next week be text again? > > Probably not - the system currently only allows for PDF output, but I've > mailed them a question about getting plain text. I've attached the output of pdftotext (from xpdf-utils on a debian system) Seems pretty clean to me. Long lines aren't wrapped (a quick pass through fmt seems to do little damage, though: attached as well). I'm a great fan of the IRC meetings and the notes, by the way: any tool that helps you get these done is a good thing. However, text is so much more flexible for these reports to the list: the followup quoting issue alone is a big one. Ross -- Ross Reedstrom, Ph.D. reeds...@rice.edu Systems Engineer & Admin, Research Scientistphone: 713-348-6166 The Connexions Project http://cnx.orgfax: 713-348-3665 Rice University MS-375, Houston, TX 77005 GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E F888 D3AE 810E 88F0 BEDE Zope Developers Meeting date: Location: Purpose/Notes: Chaired by: Minutes rec. by: Tuesday, April 13, 2010 from 3:00 PM to 3:30 PM irc://#zope Regular scheduled meeting Christian Theune Christian Theune Attendance: Present: Christian Theune Regrets: Absent: Late: Guests: (none) Meeting Documents: (no documents) Meeting Minutes: 1. Committee business Christian Theune Discussion about the KGS 3.4.1 was included into the agenda by request of Adam Groszer. 1.1. Review Agenda Launchpad bug management issues were included into the agenda by request of Tres Seaver. Item Status: Completed 2. Old business 2.1. Upcoming bug day Announcements have been send out to zope-dev, although there hasn't been much feedback. Tres reported having had a mini-bugdy by himself in between and that he has been experimenting with using bzr (and other DVCS') against the SVN server to allow others more easily to contribute without having to directly sign an agreement. Some documentation about this is available here: http://svn.repoze.org/docs/repoze/HACKING.rst Adam reported he'd be available for mentoring the bug day as did Christian Theune. Tres' will be around for at least part of the day. Otherwise we'll wait for the bug day to come. Item Status: Completed 2.2. Resurrecting "sprint schedule" page Adam Groszer wondered whether we can have something that makes upcoming sprints more visible to developers. We decided to merge this topic into the next item (General calendar). Item Status: Completed 2.3. Calendar for Zope-related events We'd like to see a general calendar that includes all kinds of Zope-related events (Sprints, Conferences, ...). As Jan Smith (VP Zope Foundation) is already working on a proposal for a general calendar we decided to Page 1 of 3 Printed: 4/15/2010 wait for her until after the next ZF board meeting. Item Status: Deferred: 4/30/2010 2.4. Test runners/nightly builds We haven't had input on this topic itself. (Personally having a "how are we doing?" status check every now and then would be nice). Item Status: Parked 2.4.1. List of projects/platforms/... for guaranteed builds We need to define the combinations of projects/platforms/Python versions etc. that we want to give a guarantee that our builds work. Adam Groszer recommended including Windows 64 into the list of platforms. Item Status: Parked 2.5. Restructuring the LP packages/bug trackers Tres' asked to stop using a single central bug tracker but split of bug tracking so that each ZTK package has its own bug tracker on LP. One of the problems of the current situation is that we get bug reports at inappropriate places. We already discussed this before but were uncomfortable with doing this right away and intended to temporarily use a central bug tracker for ZTK and then splitting of. Also, there was previous work by Christian Theune from last EuroPython where he started to create projects but got caught up in details and didn't finish. Tres' proposed to assist with the transition and Christian Theune offered to help as well. They intend to do the cleanup and start triaging before the upcoming bug day. In case of hitting stumbling blocks we'll ask Sidnei and Gary for help as they're part of the LP team. Item Status: Deferred: 4/27/2010 2.6. Release KGS
Re: [Zope-dev] KGS 3.4.1 versions
Roger a écrit : > Hi > >> Betreff: Re: [Zope-dev] KGS 3.4.1 versions >> >> Adam GROSZER a écrit : >>> Hello, >>> >>> There is a sheet with versions for KGS 3.4.1 >>> >> http://spreadsheets.google.com/pub?key=tUE5Q72d4Kg1FXaacCA3EKQ&output= >>> html >>> >>> Anyone for/against those versions? >>> >>> The open questions that remain: >>> * What about pytz 2010g? >>> * Which lxml version to take? 1.3.6? >>> * What about zope.app.container 3.6.2? >>> * Would be nice to have zope.testbrowser 3.5.1 >>> >>> Comments are welcome. >>> >> z3c.layer has a major security issue, because of trusted >> traversing adapters that removes the security proxy >> everywhere. > > yes and no, only miss use could end in security issues > It's not really a security issue, it's the only concept which allows > to use nested sites with more then one IAuthentication utility > and allows to authenticate on objects behind the first site. > > But since this was such a rare use case, we decided to split > the package in different packages which also supports a non > trusted setup. This makes the packages more general usable > without to run into security issues based on trusted > confirgurations where non trusted is needed. > >> This package has been retired and splitted into >> its 3 subpackages : >> >> z3c.layer.minimal >> z3c.layer.pagelet > > Both package above should not use trusted traverser > >> z3c.layer.trusted > > This package should still use trusted traverser > >> There is no problem upgrading to branch 1.0 of these >> packages, as they don't have any significant changes, >> excepted the splitting. However: >> >> z3c.layer.pagelet should be in version 1.0.2. Nothing below. >> z3c.layer.minimal has no corrected 1.0 branch. A new >> maintenance release 1.0.2 of this package should be released. >> z3c.layer.trusted is OK, since this is trusted in purpose. (I think) > > Yes Ok thanks, I'll release z3c.layer.minimal during the WE. > > Regards > Roger Ineichen > >> Christophe >> ___ >> Zope-Dev maillist - Zope-Dev@zope.org >> https://mail.zope.org/mailman/listinfo/zope-dev >> ** No cross posts or HTML encoding! ** (Related lists - >> https://mail.zope.org/mailman/listinfo/zope-announce >> https://mail.zope.org/mailman/listinfo/zope ) >> > > > ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Minutes from this weeks meeting
Hi, On 04/16/2010 05:18 PM, Ross J. Reedstrom wrote: > On Thu, Apr 15, 2010 at 11:31:32PM +0200, Christian Theune wrote: >> On 04/15/2010 11:27 PM, Wichert Akkerman wrote: >>> On 2010-4-15 17:59, Christian Theune wrote: Hi, here's the minutes. As I've been adventurous, I'll add a few comments: * I've started diving into the matter of how to manage items that we park/defer/postpone/wait for and thus started using an online system. (The only one I was able to find anyway.) * The output is a PDF which is currently a bit messy as I wanted to get rid of my text files that had the open issues sitting in there and thus had to add all of them to our agenda on Tuesday and then defer them. I think next week will become less noisy. >>> >>> Will next week be text again? >> >> Probably not - the system currently only allows for PDF output, but I've >> mailed them a question about getting plain text. > > I've attached the output of pdftotext (from xpdf-utils on a debian > system) Seems pretty clean to me. Long lines aren't wrapped (a quick > pass through fmt seems to do little damage, though: attached as well). > > I'm a great fan of the IRC meetings and the notes, by the way: any tool > that helps you get these done is a good thing. However, text is so much > more flexible for these reports to the list: the followup quoting issue > alone is a big one. Yeah, I looked through the pdftotext output earlier today as well and figured that I can probably get away with it and a little automated cleanup. I'll try that the next time. -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Circular dependency hell.
In my effort to port zope.component to Python 3 I constantly encounter one problem that is very hard to solve: Circular dependencies. It's hard to port module A, when running the tests require module B to be ported, and module B depends on module A. Or, as with setuptools, it actually uses itself, so it has to work before you can test if it works. (Sorry, that's just insane). So far the main circularity was that everything depended on zope.testing as a testrunner, zc.buildout for making the development environment, and zope.testing obviously depended on zope.interface etc. I solved that by also adding support for setuptools/distributes testrunner and using that instead. That fixed zope.interface, zope.event and zope.exception. These modules still have buildout configurations if you want them, but you don't need buildout anymore. zope.interface, zope.event and zope.exception can now be developed and tested with only setuptools, you can run the tests with "python setup.py test" both under Python 2 and 3. But then the time came to zope.testing itself. It, rather annoyingly, depends on itself. I did the same there, but almost all tests are even more annoyingly, doctests, and depends on a custom version of doctest included, etc, etc, etc. The result was hours and hours of minor fiddling to find exactly what character in a doctest that made it fail. So I've spent an inordinate amount of time on zope.testing, and I have come to a conclusion about it: == Suggestion 1 == I think we should deprecate zope.testing. Completely. There has been some discussion about deprecating it for something else, but I think we should just deprecate it. Just say "Don't use zope.testing, it's pure evil". We can recommend another testrunner, and it seems nose is winning the wars in the Python world there, but I don't think we necessarily need to do that. Most testrunners will find the tests by themselves, and the tests should be runnable with any testrunner, so which one you use is a minor issue. Instead the big problem with getting rid of zope.testing is that many tests use other specific features like the doctest renormalizers etc. These could possibly be extracted into separate modules so you can use them with other testrunners. But zope.testing is a mess that builds on two other messes, namely unittest (yes, it's a bloody mess, the API makes no sense) and doctest (which is a horror of a mess). unittest and doctest are horrid enough for us to not to make it worse with zope.testing in addition. The path forward there would simply be to stop depending on zope.testing for all ZTK modules. That's probably a bit of work, but I think it's worth it. So, with that in mind I today went on to zc.buildout, trying to port it to Python 3 by ripping out any usage of zope.testing. Also, the standard development mode for zc.buildout is that you run a dev.py script, that uses zc.buildout to build a buildout for zc.buildout. Obviously, this circularity is the same as I encountered in setuptools, and it's evil. But with zc.buildout it's easy to get rid off at least as I could use setuptools testrunner instead. But then I realize the zc.buildout needs zc.recipe.egg. And zc.recipe.egg depends on zc.buildout. Hohum, another circular depedency. == Suggestion 2 == Move the egg recipe into zc.buildout itself, and make zc.recipe.egg a dummy package that just points at zc.buildout.recipe.egg (or whatever we decide to call it). That solves that problem. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > > > In my effort to port zope.component to Python 3 I constantly encounter > one problem that is very hard to solve: Circular dependencies. It's > hard to port module A, when running the tests require module B to be > ported, and module B depends on module A. Or, as with setuptools, it > actually uses itself, so it has to work before you can test if it > works. (Sorry, that's just insane). > > So far the main circularity was that everything depended on > zope.testing as a testrunner, zc.buildout for making the development > environment, and zope.testing obviously depended on zope.interface > etc. I solved that by also adding support for setuptools/distributes > testrunner and using that instead. That fixed zope.interface, > zope.event and zope.exception. These modules still have buildout > configurations if you want them, but you don't need buildout anymore. > zope.interface, zope.event and zope.exception can now be developed and > tested with only setuptools, you can run the tests with "python > setup.py test" both under Python 2 and 3. Yay! That is a big win -- I'd like to see us automate testing this way, so that future development doesn't erode it. Developing ZTK packages using buildout should be a convenience, not a mandate. > But then the time came to zope.testing itself. It, rather annoyingly, > depends on itself. I did the same there, but almost all tests are even > more annoyingly, doctests, and depends on a custom version of doctest > included, etc, etc, etc. The result was hours and hours of minor > fiddling to find exactly what character in a doctest that made it > fail. So I've spent an inordinate amount of time on zope.testing, and > I have come to a conclusion about it: > > == Suggestion 1 == > > I think we should deprecate zope.testing. Completely. There has been > some discussion about deprecating it for something else, but I think > we should just deprecate it. Just say "Don't use zope.testing, it's > pure evil". We can recommend another testrunner, and it seems nose is > winning the wars in the Python world there, but I don't think we > necessarily need to do that. Most testrunners will find the tests by > themselves, and the tests should be runnable with any testrunner, so > which one you use is a minor issue. I'm +0 on this myself. Certainly I don't think that we should have packages hard-wire dependencies on zope.testing in order to run their own tests. > Instead the big problem with getting rid of zope.testing is that many > tests use other specific features like the doctest renormalizers etc. > These could possibly be extracted into separate modules so you can use > them with other testrunners. Maybe instead we should strip zope.testing down so that it includes only these bits (the ones that get imported by third-party test code), and move the testrunner out to a separate package, e.g. 'zope.testrunner'. I think Marius Gedminas already suggested such a thing: we could update zc.recipe.testrunner to use the new package, which would make existing buildouts continue to wok. > But zope.testing is a mess that builds on > two other messes, namely unittest (yes, it's a bloody mess, the API > makes no sense) and doctest (which is a horror of a mess). unittest > and doctest are horrid enough for us to not to make it worse with > zope.testing in addition. > > The path forward there would simply be to stop depending on > zope.testing for all ZTK modules. That's probably a bit of work, but I > think it's worth it. I believe that the ZTK's charter is to have its packages be widely reusable, so making them testable without a custom testrunner seems like a great idea to me. > So, with that in mind I today went on to zc.buildout, trying to port > it to Python 3 by ripping out any usage of zope.testing. Also, the > standard development mode for zc.buildout is that you run a dev.py > script, that uses zc.buildout to build a buildout for zc.buildout. > Obviously, this circularity is the same as I encountered in > setuptools, and it's evil. But with zc.buildout it's easy to get rid > off at least as I could use setuptools testrunner instead. But then I > realize the zc.buildout needs zc.recipe.egg. And zc.recipe.egg depends > on zc.buildout. Hohum, another circular depedency. Yup. I don't even know why zc.recipe.egg is broken out from buildout at all. > == Suggestion 2 == > > Move the egg recipe into zc.buildout itself, and make zc.recipe.egg a > dummy package that just points at zc.buildout.recipe.egg (or whatever > we decide to call it). That solves that problem. +1 from me. Graphs with cycles are pure evil. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG
Re: [Zope-dev] Circular dependency hell.
On Apr 16, 2010, at 1:35 PM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Lennart Regebro wrote: ... >> So, with that in mind I today went on to zc.buildout, trying to port >> it to Python 3 by ripping out any usage of zope.testing. Also, the >> standard development mode for zc.buildout is that you run a dev.py >> script, that uses zc.buildout to build a buildout for zc.buildout. >> Obviously, this circularity is the same as I encountered in >> setuptools, and it's evil. But with zc.buildout it's easy to get rid >> off at least as I could use setuptools testrunner instead. But then I >> realize the zc.buildout needs zc.recipe.egg. And zc.recipe.egg depends >> on zc.buildout. Hohum, another circular depedency. > > Yup. I don't even know why zc.recipe.egg is broken out from buildout at > all. When I was working on my "support system Python" branches of zc.buildout, I guessed it was because, if it is separate, then using zc.recipe.egg (which follows the standard ``recipe = `` idiom in the .cfg files) uses the same machinery that all the other recipes use. Yes, they are the same package, essentially, which is why zc.recipe.egg is part of the svn checkout of zc.buildout. I followed the same pattern in my branches for the z3c.recipe.scripts recipe. I certainly don't feel strongly about it, but it didn't seem outrageous to me. > >> == Suggestion 2 == >> >> Move the egg recipe into zc.buildout itself, and make zc.recipe.egg a >> dummy package that just points at zc.buildout.recipe.egg (or whatever >> we decide to call it). That solves that problem. > > +1 from me. Graphs with cycles are pure evil. I sure which my branches would land first, if they are ever to land. Any changes to buildout are a pain. Big changes are a big pain. Gary ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Fri, Apr 16, 2010 at 6:05 PM, Lennart Regebro wrote: ... > == Suggestion 1 == > > I think we should deprecate zope.testing. Completely. There has been > some discussion about deprecating it for something else, but I think > we should just deprecate it. Just say "Don't use zope.testing, it's > pure evil". We can recommend another testrunner, and it seems nose is > winning the wars in the Python world there, but I don't think we > necessarily need to do that. Most testrunners will find the tests by > themselves, and the tests should be runnable with any testrunner, so > which one you use is a minor issue. As the author of one of those other testrunners, I can tell you that if you do this you'll find that your number one biggest problem is getting layers to work. > But zope.testing is a mess that builds on > two other messes, namely unittest (yes, it's a bloody mess, the API > makes no sense) and doctest (which is a horror of a mess). unittest's API makes sense and it's not a mess. It's got problems, but they are defects and not bone-deep. Further, the current maintainer of unittest, Michael Foord, has been doing some excellent work in addressing those defects. The testing-in-python mailing list[1] is probably the best place to take up the issue if you wish to do so. jml [1] http://lists.idyll.org/listinfo/testing-in-python ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] zope.publisher release?
Would someone please add me (kteague) to the zope.publisher maintainers list on PyPI, or do a new zope.publisher release? I want to get the fix for the xml-rpc hang in Grok out there: https://bugs.launchpad.net/grok/+bug/332063 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Fri, Apr 16, 2010 at 19:53, Jonathan Lange wrote: > As the author of one of those other testrunners, I can tell you that > if you do this you'll find that your number one biggest problem is > getting layers to work. Ah, right, layers are in zope.testing too. To actually get widespread movement from zope.testing we would have to make some other layer support. Hm... > unittest's API makes sense and it's not a mess. No, the API to run tests doesn't make any sense, but we can take that discussion some other day. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Fri, Apr 16, 2010 at 19:48, Gary Poster wrote: > When I was working on my "support system Python" branches of zc.buildout, I > guessed it was because, if it is separate, then using zc.recipe.egg (which > follows the standard ``recipe = `` idiom in the .cfg files) uses the same > machinery that all the other recipes use. > > Yes, they are the same package, essentially, which is why zc.recipe.egg is > part of the svn checkout of zc.buildout. > > I followed the same pattern in my branches for the z3c.recipe.scripts recipe. > > I certainly don't feel strongly about it, but it didn't seem outrageous to me. One problem with it is that it's tricky to work on two modules at once, unless you have buildout... And since I in my branch removed the buildouts usage of itself, I don't. So that means that zc.buildout doens't have zc.recipe.egg, unless I install it, which I can't, becuase I haven't ported it yet, which I can't do untill I posrt zc. buildout which... yeah, you get it. Outrageous? No. Bad? Yes. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On Fri, Apr 16, 2010 at 19:35, Tres Seaver wrote: >>> == Suggestion 1 == >>> >>> I think we should deprecate zope.testing. Completely. There has been >>> some discussion about deprecating it for something else, but I think >>> we should just deprecate it. Just say "Don't use zope.testing, it's >>> pure evil". We can recommend another testrunner, and it seems nose is >>> winning the wars in the Python world there, but I don't think we >>> necessarily need to do that. Most testrunners will find the tests by >>> themselves, and the tests should be runnable with any testrunner, so >>> which one you use is a minor issue. >> I'm +0 on this myself. Certainly I don't think that we should have >> packages hard-wire dependencies on zope.testing in order to run their >> own tests. >> >>> Instead the big problem with getting rid of zope.testing is that many >>> tests use other specific features like the doctest renormalizers etc. >>> These could possibly be extracted into separate modules so you can use >>> them with other testrunners. >> Maybe instead we should strip zope.testing down so that it includes only >> these bits (the ones that get imported by third-party test code), and >> move the testrunner out to a separate package, e.g. 'zope.testrunner'. >> I think Marius Gedminas already suggested such a thing: we could update >> zc.recipe.testrunner to use the new package, which would make existing >> buildouts continue to wok. > > That would be an improvement at least. Maybe we can determine what is > actually in zope.testing and see what can be split out. > > I know of three parts: > > 1. The testrunner. Right: moving it out would clarify. > 2. The special doctest Already deprecated in favor of the stdlib module. and a module called doctestunit, of unclear use. It is already deprecated, contains nothing but BBB imports and a funky wrapper or ppprint.pprint (the way the wrapper is constructed is pretty insane). Unfortunately, it is widely used in ZTK tests, mostly in ways which should be replace with the stdlib doctest module. The ``pprint`` function could be moved into a new module, perhaps. > 3. The doctest renormalizers. > 4. Anything else? :mod:`zope.testing.exceptions` used only by the custom doctest and the testrunner. It could just move to the testrunner. :mod:`zope.testing.formparser` Parses rendered HTML forms back to datastructures. Maybe useful in tests which consume rendered output. No ZTK tests use this module. :mod:`zope.testing.loggingsupport` Enable assertions about how code uses Python's logging module. No ZTK tests use this module. Tests in :mod:`zc.buildout`, :mod:`zope.app.appsetup`, :mod:`ZODB`, and :mod:`zc.lockfile` use this module. :mod:`zope.testing.loghandler` *Another* module enabling assertions about how code uses Python's logging module. No ZTK tests use this module. :mod:`zope.testing.module` Support for jamming a dummy module into sys.modules, and getting it out again in a testcase's tearDown.. Tests in :mod:`zope.copy` and :mod:`zope.container` use this module. Tests in :mod:`ZODB` also use this module :mod:`zope.testing.server` Runs an HTTP server (?!) in the middle of a functional test, and uses the stdlib 'webbrowser' module to make a request. No ZTK tests use this module. :mod:`zope.testing.setupstack` Support for chaining together teardown functions in a stack No ZTK tests use this module. Tests in :mod:`ZODB` and :mod:`zc.lockfile` use this module. > I think the doctest renormalizers can be used with standard doctest, > so it might be feasible to extract those as well? How about we move out the testrunner (including updating zc.recipe.testrunner), clean out any remaining cruft, and release a new major version containing only bits used in real-world tests? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@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 iEYEARECAAYFAkvIrw4ACgkQ+gerLs4ltQ4NCgCfaDGjIy3+dJs0EfkNEC47GdcI ITIAoNmNVBE1GBF12nzi6JAKOpdxxE52 =ZlJ4 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Fri, Apr 16, 2010 at 20:40, Tres Seaver wrote: > How about we move out the testrunner (including updating > zc.recipe.testrunner), clean out any remaining cruft, and release a new > major version containing only bits used in real-world tests? Sounds like a good plan to me. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Fri, Apr 16, 2010 at 2:40 PM, Tres Seaver wrote: > :mod:`zope.testing.formparser` > Parses rendered HTML forms back to datastructures. Maybe useful > in tests which consume rendered output. > > No ZTK tests use this module. I believe this may be used in tests of some of the zope.app.* packages; I don't recall which ones. This predates zope.testbrowser; users should consider migrating to that. > :mod:`zope.testing.loggingsupport` > Enable assertions about how code uses Python's logging module. > > No ZTK tests use this module. > > Tests in :mod:`zc.buildout`, :mod:`zope.app.appsetup`, :mod:`ZODB`, > and :mod:`zc.lockfile` use this module. Many application tests use this module. > :mod:`zope.testing.module` > Support for jamming a dummy module into sys.modules, and getting > it out again in a testcase's tearDown.. > > Tests in :mod:`zope.copy` and :mod:`zope.container` use this module. > > Tests in :mod:`ZODB` also use this module Many application tests use this module. > :mod:`zope.testing.setupstack` > Support for chaining together teardown functions in a stack > > No ZTK tests use this module. > > Tests in :mod:`ZODB` and :mod:`zc.lockfile` use this module. Many application tests use this as well. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Launchpad gardening
On Thu, Apr 15, 2010 at 9:40 PM, Tres Seaver wrote: > Turns out not to be too tough, given the git and mercurial examples to > stare at: > > lp:~tseaver/mr.developer/bzr_sources > > I have only tested it lightly so far, but it does seem at least to get > the initial checkouts done using bzr (even against svn+ssh:// URLs!). I tried to get this branch, but it depends on lp:~tseaver/mr.developer/trunk, which hasn't been pushed to. -- Sidnei ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Launchpad gardening
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sidnei da Silva wrote: > On Thu, Apr 15, 2010 at 9:40 PM, Tres Seaver wrote: >> Turns out not to be too tough, given the git and mercurial examples to >> stare at: >> >> lp:~tseaver/mr.developer/bzr_sources >> >> I have only tested it lightly so far, but it does seem at least to get >> the initial checkouts done using bzr (even against svn+ssh:// URLs!). > > I tried to get this branch, but it depends on > lp:~tseaver/mr.developer/trunk, which hasn't been pushed to. Ugh. I reassigned ownership of the trunk branch to 'mr.developer-team', and made Florian Schulze a member of the team, so that I would be "poaching". I guess I should delete my branch and re-push from a checkout of my git repository? Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@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 iEYEARECAAYFAkvIuggACgkQ+gerLs4ltQ4MCACcDq+1+g0PW/1DBrHx1gLIG89W t3AAn0yN3y+IuzVTAw7u0wu5UHBoxBYk =70xy -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Minutes from this weeks meeting
On 2010-4-16 17:34, Christian Theune wrote: > On 04/16/2010 05:18 PM, Ross J. Reedstrom wrote: >> I've attached the output of pdftotext (from xpdf-utils on a debian >> system) Seems pretty clean to me. Long lines aren't wrapped (a quick >> pass through fmt seems to do little damage, though: attached as well). >> >> I'm a great fan of the IRC meetings and the notes, by the way: any tool >> that helps you get these done is a good thing. However, text is so much >> more flexible for these reports to the list: the followup quoting issue >> alone is a big one. > > Yeah, I looked through the pdftotext output earlier today as well and > figured that I can probably get away with it and a little automated > cleanup. I'll try that the next time. Thank you both! W. -- Wichert AkkermanIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Repository for the zope mail summarizer
Hi, I wanted to look into the script that summarizes the mails sent to zope-test. The best code I found is this http://cvs.zope.org/Packages/TestScripts/ but I suspect that there are newer versions, I just don't know where. I'd like modifiy the script to understand status mails from buildbots too. Anybody knows where the latest version of this code is? And who runs that script atm? Best regards, Patrick ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Repository for the zope mail summarizer
On Fri, Apr 16, 2010 at 9:55 PM, Patrick Gerken wrote: > And who runs that script atm? Talk to testmaster Stefan Holek , stefan (at) epy dot co dot at He wrote the script and runs it. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Fri, Apr 16, 2010 at 20:43, Lennart Regebro wrote: > On Fri, Apr 16, 2010 at 20:40, Tres Seaver wrote: >> How about we move out the testrunner (including updating >> zc.recipe.testrunner), clean out any remaining cruft, and release a new >> major version containing only bits used in real-world tests? > > Sounds like a good plan to me. The renormalizers are used by the testrunner tests, so I think they possibly also needs separating, unless we make zope.tesrunner depend on zope.testing, but then I'm not sure if we gained much. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Launchpad gardening
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tres Seaver wrote: > Sidnei da Silva wrote: >> On Thu, Apr 15, 2010 at 9:40 PM, Tres Seaver wrote: >>> Turns out not to be too tough, given the git and mercurial examples to >>> stare at: >>> >>> lp:~tseaver/mr.developer/bzr_sources >>> >>> I have only tested it lightly so far, but it does seem at least to get >>> the initial checkouts done using bzr (even against svn+ssh:// URLs!). >> I tried to get this branch, but it depends on >> lp:~tseaver/mr.developer/trunk, which hasn't been pushed to. > > Ugh. I reassigned ownership of the trunk branch to 'mr.developer-team', > and made Florian Schulze a member of the team, so that I would be > "poaching". I guess I should delete my branch and re-push from a > checkout of my git repository? That repository is here: http://github.com/tsesver/mr.developer Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@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 iEYEARECAAYFAkvIx6QACgkQ+gerLs4ltQ72WgCZAaD3hDzPELSiI/u7En/IbWHs 5kMAn26uucC0V6X9ND8ipPRuOWsfkA6X =43dE -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Drake wrote: > On Fri, Apr 16, 2010 at 2:40 PM, Tres Seaver wrote: >> :mod:`zope.testing.formparser` >>Parses rendered HTML forms back to datastructures. Maybe useful >>in tests which consume rendered output. >> >>No ZTK tests use this module. > > I believe this may be used in tests of some of the zope.app.* > packages; I don't recall which ones. > > This predates zope.testbrowser; users should consider migrating to that. > >> :mod:`zope.testing.loggingsupport` >>Enable assertions about how code uses Python's logging module. >> >>No ZTK tests use this module. >> >>Tests in :mod:`zc.buildout`, :mod:`zope.app.appsetup`, :mod:`ZODB`, >>and :mod:`zc.lockfile` use this module. > > Many application tests use this module. > >> :mod:`zope.testing.module` >>Support for jamming a dummy module into sys.modules, and getting >>it out again in a testcase's tearDown.. >> >>Tests in :mod:`zope.copy` and :mod:`zope.container` use this module. >> >>Tests in :mod:`ZODB` also use this module > > Many application tests use this module. > >> :mod:`zope.testing.setupstack` >>Support for chaining together teardown functions in a stack >> >>No ZTK tests use this module. >> >>Tests in :mod:`ZODB` and :mod:`zc.lockfile` use this module. > > Many application tests use this as well. Good to know, thanks. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@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 iEYEARECAAYFAkvIyCAACgkQ+gerLs4ltQ5vigCffNKHLdcQdXFQMFmgrxfoELXF 6cEAn0s2V2KiO33nwCA1FNFRaNUnXThp =f0Gm -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.publisher release?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevin Teague wrote: > Would someone please add me (kteague) to the zope.publisher maintainers list > on PyPI, or do a new zope.publisher release? > > I want to get the fix for the xml-rpc hang in Grok out there: > https://bugs.launchpad.net/grok/+bug/332063 Done. Please update the zopetoolkit/trunk/ztk.cfg as well. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@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 iEYEARECAAYFAkvIyesACgkQ+gerLs4ltQ6mxgCfUKMe4msQ1uBTGp3iSo42JrlB NDkAoMN0AyLQwurNwGRcFfJLY82aHU3p =qYQ8 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lennart Regebro wrote: > On Fri, Apr 16, 2010 at 20:43, Lennart Regebro wrote: >> On Fri, Apr 16, 2010 at 20:40, Tres Seaver wrote: >>> How about we move out the testrunner (including updating >>> zc.recipe.testrunner), clean out any remaining cruft, and release a new >>> major version containing only bits used in real-world tests? >> Sounds like a good plan to me. > > The renormalizers are used by the testrunner tests, so I think they > possibly also needs separating, unless we make zope.tesrunner depend > on zope.testing, but then I'm not sure if we gained much. :) We will have factored the "reusable" bits (which we know get re-used) into a smaller, cleaner package, which should (I hope) be easier to port. Other packages which depend on only those bits should be more easily testable without the testrunner, and therefore easier to port as well. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@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 iEYEARECAAYFAkvIzCIACgkQ+gerLs4ltQ5URQCbBN5C5yBBejUXADc9RZA8NAcA 6/wAnAwdLSjvuFXoI97r+qOTuAO7rxe/ =Alpv -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Fri, Apr 16, 2010 at 22:44, Tres Seaver wrote: > We will have factored the "reusable" bits (which we know get re-used) > into a smaller, cleaner package, which should (I hope) be easier to port. > > Other packages which depend on only those bits should be more easily > testable without the testrunner, and therefore easier to port as well. Yeah, could work. I'm looking at separating the testrunner now. And the testrunner tests use the renormalizer (which is clean and portable) and the loggingsupport (which I haven't looked at yet). -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] RFC: Proposed new style for documenting and testing ZTK packages
-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 tsea...@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- The first patch adds docs generated via 'sphinx-quickstart. revno: 37 committer: Tres Seaver branch nick: event timestamp: Fri 2010-04-16 18:00:23 -0400 message: Add Sphinx documentation. diff: === added directory 'docs' === added file 'docs/Makefile' --- docs/Makefile 1970-01-01 00:00:00 + +++ docs/Makefile 2010-04-16 22:00:23 + @@ -0,0 +1,89 @@ +# Makefile for Sphinx documentation +# + +# You can set these variables from the command line. +SPHINXOPTS= +SPHINXBUILD = sphinx-build +PAPER = +BUILDDIR = _build + +# Internal variables. +PAPEROPT_a4 = -D latex_paper_size=a4 +PAPEROPT_letter = -D latex_paper_size=letter +ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) . + +.PHONY: help clean html dirhtml pickle json htmlhelp qthelp latex changes linkcheck doctest + +help: + @echo "Please use \`make ' where is one of" + @echo " html to make standalone HTML files" + @echo " dirht
Re: [Zope-dev] Circular dependency hell.
Hi Lennart & co, On 17 April 2010 02:38, Lennart Regebro wrote: > On Fri, Apr 16, 2010 at 19:53, Jonathan Lange wrote: >> As the author of one of those other testrunners, I can tell you that >> if you do this you'll find that your number one biggest problem is >> getting layers to work. > > Ah, right, layers are in zope.testing too. To actually get widespread > movement from zope.testing we would have to make some other layer > support. Hm... As you may know, I've been working on plone.testing. This is mainly to make it easier for people working on Plone packages to write "good" tests (and a lot of it is just about patterns, rather than code), but in fact it doesn't depend on Plone (and only soft-depends on Zope 2). I'm certainly hoping to use it for my "plain Zope 3/Toolkit" packages in the future. plone.testing makes very heavy use of layers. I think layers are a great feature, when done properly, and I haven't seen any better approach. The setUpClass/setUpModule stuff in unittest2 is nice, but doesn't really solve the same problem. For integration testing with something as complex as Zope 2 (or, arguably, the ZODB, various bits of the ZTK, and so on) layers allow "us" the framework authors to make life much easier for those people who are not experts in the framework. Anyway, a few high level observations: - In neither plone.testing (apart from its own tests), nor in code that uses it, would I imagine actually depending on zope.testing via an import. We use unittest(2) and doctest from the standard library. - We do depend on a zope.testing-compatible test runner, in that we expect layers to work. In reality, we depend on zc.recipe.testrunner, though I would *love* to be able to do 'python setup.py test' as well (and have that execute tests with layers). I have no idea how that works or whether it'd be possible. - The way zope.testing promotes writing layers is actually pretty evil. It overloads the 'class' keyword, essentially, making you spell "base layers" as base classes. This has a few problems: - If your "base layer" has a testTearDown method, say, and your layer doesn't, the base class version will actually inherit into the child layer. zope.testing will then run the same code twice, once for the base layer and once for the child layer. - You can't use OOP inheritance to re-use layer conveniences. - People get quite confused. :) - You can't have two copies of a layer - all layers are module-level global singletons. This becomes somewhat important when layers manage and expose resources (like database connections). Anyway, based on Ross Patterson's work in collective.testcaselayer, I think we have something better in plone.testing's layer module. General info and patterns: http://svn.plone.org/svn/plone/plone.testing/trunk/README.txt Layer module: http://svn.plone.org/svn/plone/plone.testing/trunk/src/plone/testing/layer.py Layer doctests: http://svn.plone.org/svn/plone/plone.testing/trunk/src/plone/testing/layer.txt If I could have my cake and eat it too, I'd like: - A test runner that supports layers - A test runner that supports the new fixture methods in unittest2/Python 2.7 - setUpClass and setUpModule - A test runner that properly reports skipped tests (pretty easy) - A test runner that supports the above begin run from 'setup.py test' - A test runner installable via a buildout part just like zc.recipe.testrunner We could quite possibly factor layer.py out of plone.testing and push it into something else if that was desirable. It's self-contained and has no dependencies. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposed new style for documenting and testing ZTK packages
On 17 April 2010 09:41, Tres Seaver wrote: > -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. > Thoughts? +1000, to both aim and approach. :) Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Circular dependency hell.
On Sat, Apr 17, 2010 at 06:34, Martin Aspeli wrote: > Hi Lennart & co, > > On 17 April 2010 02:38, Lennart Regebro wrote: >> On Fri, Apr 16, 2010 at 19:53, Jonathan Lange wrote: >>> As the author of one of those other testrunners, I can tell you that >>> if you do this you'll find that your number one biggest problem is >>> getting layers to work. >> >> Ah, right, layers are in zope.testing too. To actually get widespread >> movement from zope.testing we would have to make some other layer >> support. Hm... > > As you may know, I've been working on plone.testing. This is mainly to > make it easier for people working on Plone packages to write "good" > tests (and a lot of it is just about patterns, rather than code), but > in fact it doesn't depend on Plone (and only soft-depends on Zope 2). > I'm certainly hoping to use it for my "plain Zope 3/Toolkit" packages > in the future. > > plone.testing makes very heavy use of layers. I think layers are a > great feature, when done properly, and I haven't seen any better > approach. The setUpClass/setUpModule stuff in unittest2 is nice, but > doesn't really solve the same problem. For integration testing with > something as complex as Zope 2 (or, arguably, the ZODB, various bits > of the ZTK, and so on) layers allow "us" the framework authors to make > life much easier for those people who are not experts in the > framework. > > Anyway, a few high level observations: > > - In neither plone.testing (apart from its own tests), nor in code > that uses it, would I imagine actually depending on zope.testing via > an import. We use unittest(2) and doctest from the standard library. > > - We do depend on a zope.testing-compatible test runner, in that we > expect layers to work. In reality, we depend on zc.recipe.testrunner, > though I would *love* to be able to do 'python setup.py test' as well > (and have that execute tests with layers). I have no idea how that > works or whether it'd be possible. > > - The way zope.testing promotes writing layers is actually pretty > evil. It overloads the 'class' keyword, essentially, making you spell > "base layers" as base classes. This has a few problems: > > - If your "base layer" has a testTearDown method, say, and your > layer doesn't, the base class version will actually inherit into the > child layer. zope.testing will then run the same code twice, once for > the base layer and once for the child layer. > > - You can't use OOP inheritance to re-use layer conveniences. > > - People get quite confused. :) > > - You can't have two copies of a layer - all layers are > module-level global singletons. This becomes somewhat important when > layers manage and expose resources (like database connections). > > Anyway, based on Ross Patterson's work in collective.testcaselayer, I > think we have something better in plone.testing's layer module. Aha, interesting. > General info and patterns: > http://svn.plone.org/svn/plone/plone.testing/trunk/README.txt > Layer module: > http://svn.plone.org/svn/plone/plone.testing/trunk/src/plone/testing/layer.py > Layer doctests: > http://svn.plone.org/svn/plone/plone.testing/trunk/src/plone/testing/layer.txt > > If I could have my cake and eat it too, I'd like: > > - A test runner that supports layers > - A test runner that supports the new fixture methods in > unittest2/Python 2.7 - setUpClass and setUpModule > - A test runner that properly reports skipped tests (pretty easy) > - A test runner that supports the above begin run from 'setup.py test' > - A test runner installable via a buildout part just like > zc.recipe.testrunner > > We could quite possibly factor layer.py out of plone.testing and push > it into something else if that was desirable. It's self-contained and > has no dependencies. All this sounds good and not to complicated compared to extracting the testrunner itself. :) Which in turn is less complicated than the work you've already done. :) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposed new style for documenting and testing ZTK packages
On Sat, Apr 17, 2010 at 03:41, Tres Seaver wrote: > -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? +lots. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] RFC: Proposed new style for documenting and testing ZTK packages
(Although possible we could call it "developing" instead of "hacking" but that's not a big issue. ;) ) -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
