Re: [Zope-dev] z3c.form 2.0 release?
Hello Malthe, The problem that I see here with lxml is that it is used for output checking. Even worse z3c.form requires at least 2.1.1 of lxml, where KGS 3.4 has lxml nailed at 1.3.6. This burpes already on buildout. Now even if I would ignore this requirement for testing, (and testing) how could I be sure that tests pass (with KGS 3.4)? Take a look at svn://svn.zope.org/repos/main/z3c.form/branches/adamg-z3c-pt-optional and try to make the tests work and pass. Look out, buildout.cfg has the KGS temporarily. Thursday, May 21, 2009, 10:10:33 AM, you wrote: MB 2009/5/21 Adam GROSZER agros...@gmail.com: Well, the strong target is to make z3c.form 2.0 compatible with KGS 3.4. (z3c.pt is somehow intertwined with z3c.ptcompat too.) That's the goal am chasing though I'm quite busy right now. MB I don't know the implications of requiring zope.i18n = 3.5, but I can MB say that it's the only dependency that could somehow cause MB difficulties. Neither z3c.pt nor z3c.ptcompat have any odd MB dependencies (package or version-wise). MB Perhaps it's the obsolete dependency on lxml that's causing confusion; MB I read a post or two on the list rightfully mentioning that this was a MB very difficult dependency indeed. MB I think at this point that z3c.form could have a strong dependency on MB z3c.pt. Complete list of extra packages: MB - z3c.pt MB - chameleon.core MB - chameleon.zpt MB - sourcecodegen MB \malthe MB ___ MB Zope-Dev maillist - Zope-Dev@zope.org MB http://mail.zope.org/mailman/listinfo/zope-dev MB ** No cross posts or HTML encoding! ** MB (Related lists - MB http://mail.zope.org/mailman/listinfo/zope-announce MB http://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZERmailto:agros...@gmail.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Martijn Faassen wrote: So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http I fixed those tonight. On the trunk, there are no longer any dependencies between zope.app.publisher, zope.app.publication, and zope.app.http, except testing dependencies. Here is a summary of what I did: - Moved the publication traversal code to zope.traversing and simplified it from 3 classes to 1. This did not increase the dependencies of zope.traversing at all, since publication traversal is only slightly different from the traversal logic already in zope.traversing. It also opens the doors for someday moving the gnarly traversal code in zope.publisher to something saner in zope.traversing. - Moved an XML-RPC view registration from zope.app.publisher to zope.app.publication. - Moved IHTTPException, IMethodNotAllowed, and the MethodNotAllowed exception class to zope.publisher.interfaces.http. This move decoupled zope.app.http from zope.app.publication. - Moved getDefaultViewName() and queryDefaultViewName() to zope.publisher.defaultview. If you look at the commit messages, you'll see that I first attempted a different move that included the browser:defaultView handler, but that move turned out wrong for other packages and I reverted it. - I used zope.deferred to deprecate things I moved from zope.app.publication, zope.app.publisher, and zope.app.http. Are there any objections to using zope.deferred in those packages? In all, I changed 6 packages. Should I release them now, or should I look for other dependencies we might clean up at the same time? The changed packages are: zope.traversing (3.7.0) zope.publisher (3.8.0) zope.app.publisher (3.8.0) zope.app.publication (3.7.0) zope.app.http (3.6.0) zope.app.zcmlfiles (3.5.5; bugfix only) Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Shane Hathaway wrote: Martijn Faassen wrote: So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http I fixed those tonight. On the trunk, there are no longer any dependencies between zope.app.publisher, zope.app.publication, and zope.app.http, except testing dependencies. I should take a moment to describe the different purposes of these packages as I see them now. Conceptually, they are really quite independent. - zope.app.publisher: A library of ZCML directives for configuring views. Also provides generic view classes. A better name for this package might be zope.basicviews. A lot of packages depend on this. - zope.app.publication: Provides IPublication implementations and a mechanism/registry for choosing a different publication class for each request. Most packages should not depend on this. A better name might be zope.publicationregistry. - zope.app.http: Provides generic views that translate HTTP verbs like PUT, DELETE, and OPTIONS into map operations. The idea is clever, but not everyone needs a REST-style API. A better name might be zope.httpverbs. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] z3c.form 2.0 release?
2009/5/23 Adam GROSZER agros...@gmail.com: The problem that I see here with lxml is that it is used for output checking. Even worse z3c.form requires at least 2.1.1 of lxml, where KGS 3.4 has lxml nailed at 1.3.6. It might be possible to shed this testing dependency; ``lxml`` is used because of its doctest-mode, but since then, Chameleon has been equipped to render attributes in the ZPT order (instead of more or less random). This was the raison d'etre to use lxml in tests. This burpes already on buildout. Now even if I would ignore this requirement for testing, (and testing) how could I be sure that tests pass (with KGS 3.4)? Yes, I agree with that observation. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Fri May 22 12:00:00 2009 UTC to Sat May 23 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Fri May 22 20:53:08 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011769.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Fri May 22 20:55:10 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011770.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Fri May 22 20:57:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011771.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Fri May 22 20:59:14 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011772.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Fri May 22 21:01:15 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011773.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Fri May 22 21:03:21 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011774.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Fri May 22 21:05:24 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011775.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Fri May 22 21:07:31 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011776.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Shane Hathaway wrote: Martijn Faassen wrote: So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http I fixed those tonight. On the trunk, there are no longer any dependencies between zope.app.publisher, zope.app.publication, and zope.app.http, except testing dependencies. Cool! Thanks very much! Here is a summary of what I did: [snip summary] - I used zope.deferred to deprecate things I moved from zope.app.publication, zope.app.publisher, and zope.app.http. Are there any objections to using zope.deferred in those packages? No objection, but what's the reason to use zope.deferred instead of straight imports or zope.deprecation? To break the dependencies? In all, I changed 6 packages. Should I release them now, or should I look for other dependencies we might clean up at the same time? I'm +1 on releasing now. (and thanks for making them feature releases) Getting these things out there gives everybody who plays with this nicer dependency graphs and this tends to help improvement. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Hey Shane, Shane Hathaway wrote: Shane Hathaway wrote: Martijn Faassen wrote: So, the only dependency cycles left in zope.app.publisher are these: zope.app.publisher -- zope.app.publication -- zope.app.http I fixed those tonight. On the trunk, there are no longer any dependencies between zope.app.publisher, zope.app.publication, and zope.app.http, except testing dependencies. I should take a moment to describe the different purposes of these packages as I see them now. Conceptually, they are really quite independent. Thanks for doing this analysis, and considering improved naming. I think good naming is very important, and it will help get this functionality out of the 'zope.app' ghetto. - zope.app.publisher: A library of ZCML directives for configuring views. Also provides generic view classes. A better name for this package might be zope.basicviews. A lot of packages depend on this. I'm not sure 'basic' needs to be in there. Do we have anything less basic? What about simply calling it zope.view? (I don't like the plural in package names either generally) - zope.app.publication: Provides IPublication implementations and a mechanism/registry for choosing a different publication class for each request. Most packages should not depend on this. A better name might be zope.publicationregistry. I'm fine with this. I was considering 'zope.publication', but we already have 'zope.publisher' so that'd get very confusing again, something we should avoid. - zope.app.http: Provides generic views that translate HTTP verbs like PUT, DELETE, and OPTIONS into map operations. The idea is clever, but not everyone needs a REST-style API. A better name might be zope.httpverbs. Even though I don't really like the plural, I think 'zope.http' would promise a bit too much, so 'zope.httpverbs' sound better. So if we get some consensus about this, we need volunteers that can help move the code over to these new packages and leave backwards compatible imports in the old places. Is there anything in these packages we can safely leave behind do you think? (ZMI related, perhaps?) Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Martijn Faassen wrote: Shane Hathaway wrote: - I used zope.deferred to deprecate things I moved from zope.app.publication, zope.app.publisher, and zope.app.http. Are there any objections to using zope.deferred in those packages? No objection, but what's the reason to use zope.deferred instead of straight imports or zope.deprecation? To break the dependencies? I had forgotten about zope.deprecation. :-) I'll switch to that. In all, I changed 6 packages. Should I release them now, or should I look for other dependencies we might clean up at the same time? I'm +1 on releasing now. (and thanks for making them feature releases) Getting these things out there gives everybody who plays with this nicer dependency graphs and this tends to help improvement. Ok, I intend to release them today. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
On Sat, May 23, 2009 at 08:59:34PM +0200, Martijn Faassen wrote: What about simply calling it zope.view? (I don't like the plural in package names either generally) FWIW at some point I decided that singular is appropriate when a package defines a concept, and plural is appropriate when a package provides multiple implementations of that concept. Thus you have zope.interface but zope.$anything.interfaces. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Shane Hathaway wrote: Martijn Faassen wrote: Shane Hathaway wrote: In all, I changed 6 packages. Should I release them now, or should I look for other dependencies we might clean up at the same time? I'm +1 on releasing now. (and thanks for making them feature releases) Getting these things out there gives everybody who plays with this nicer dependency graphs and this tends to help improvement. Ok, I intend to release them today. Done. I look forward to seeing the changes in the dependency graph. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Martijn Faassen wrote: Shane Hathaway wrote: - zope.app.publisher: A library of ZCML directives for configuring views. Also provides generic view classes. A better name for this package might be zope.basicviews. A lot of packages depend on this. I'm not sure 'basic' needs to be in there. Do we have anything less basic? What about simply calling it zope.view? (I don't like the plural in package names either generally) Sounds good to me. - zope.app.publication: Provides IPublication implementations and a mechanism/registry for choosing a different publication class for each request. Most packages should not depend on this. A better name might be zope.publicationregistry. I'm fine with this. I was considering 'zope.publication', but we already have 'zope.publisher' so that'd get very confusing again, something we should avoid. Right. - zope.app.http: Provides generic views that translate HTTP verbs like PUT, DELETE, and OPTIONS into map operations. The idea is clever, but not everyone needs a REST-style API. A better name might be zope.httpverbs. Even though I don't really like the plural, I think 'zope.http' would promise a bit too much, so 'zope.httpverbs' sound better. Another option is zope.rest, because a simple REST interface is what the package tries to accomplish. So if we get some consensus about this, we need volunteers that can help move the code over to these new packages and leave backwards compatible imports in the old places. Is there anything in these packages we can safely leave behind do you think? (ZMI related, perhaps?) I haven't come across anything we'd want to leave behind. Summarizing: zope.app.publisher - zope.view zope.app.publication - zope.publicationregistry zope.app.http - zope.rest Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] package dependency refactoring progress report
Marius Gedminas wrote: On Sat, May 23, 2009 at 08:59:34PM +0200, Martijn Faassen wrote: What about simply calling it zope.view? (I don't like the plural in package names either generally) FWIW at some point I decided that singular is appropriate when a package defines a concept, and plural is appropriate when a package provides multiple implementations of that concept. Thus you have zope.interface but zope.$anything.interfaces. In this case it's a plural of metaconfiguration. Maybe zope.viewzcml? I think that would express the intent even better. Shane ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
