Re: [Zope-dev] Zope 2.13 - release candidate blockers
On 10/18/10 1:20 PM, Tres Seaver wrote: > On 10/17/2010 10:10 AM, Hanno Schlichting wrote: > > Hi. > > > With the release of both a final ZODB 3.10 and the ZTK 1.0, we are > > good to go on a release candidate for Zope 2.13. > > > There's currently two bugs I consider blockers for the release > candidate: > > > - zopectl start - doen't work > (https://bugs.launchpad.net/zope2/+bug/628448) > > - Zope2 egg is not available in index > > (https://bugs.launchpad.net/zope2/+bug/653546) > > > I will take care of the egg in index problem. > > > If anyone has time to look into the zopectl problem, that would be > > much appreciated. Once this problem is solved I'll release a rc1 and > > if no problems are found a final release a week after. > > Hmm, another note here: davisagli fixed this bug on the 2.12 bracnh two > weeks after it was checked in (a year ago now). Somehow, that fix > didn't get propagated to the trunk. Oops! Sorry I missed that; thanks for taking care of it. -- David Glick Web Developer davidgl...@groundwire.org 206.286.1235x32 Groundwire: You Are Connected http://groundwire.org We're celebrating 15 years! Come to our big party. http://groundwire.org/events/groundwires-15th-anniversary-party ___ 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 2.13 - release candidate blockers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/17/2010 10:10 AM, Hanno Schlichting wrote: > Hi. > > With the release of both a final ZODB 3.10 and the ZTK 1.0, we are > good to go on a release candidate for Zope 2.13. > > There's currently two bugs I consider blockers for the release candidate: > > - zopectl start - doen't work (https://bugs.launchpad.net/zope2/+bug/628448) > - Zope2 egg is not available in index > (https://bugs.launchpad.net/zope2/+bug/653546) > > I will take care of the egg in index problem. > > If anyone has time to look into the zopectl problem, that would be > much appreciated. Once this problem is solved I'll release a rc1 and > if no problems are found a final release a week after. Hmm, another note here: davisagli fixed this bug on the 2.12 bracnh two weeks after it was checked in (a year ago now). Somehow, that fix didn't get propagated to the trunk. 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky8rAwACgkQ+gerLs4ltQ4iyACcDvKfwf/5974Im2fSSikb4Q/f ZXMAoMR7xs6uT2Yr/3AXsx/xTti95kan =nEmc -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 2.13 - release candidate blockers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/17/2010 10:10 AM, Hanno Schlichting wrote: > Hi. > > With the release of both a final ZODB 3.10 and the ZTK 1.0, we are > good to go on a release candidate for Zope 2.13. > > There's currently two bugs I consider blockers for the release candidate: > > - zopectl start - doen't work (https://bugs.launchpad.net/zope2/+bug/628448) > - Zope2 egg is not available in index > (https://bugs.launchpad.net/zope2/+bug/653546) > > I will take care of the egg in index problem. > > If anyone has time to look into the zopectl problem, that would be > much appreciated. Once this problem is solved I'll release a rc1 and > if no problems are found a final release a week after. This is a think-o in the latest attempt to make zopectl "Just Work" on Windows (Withers, are you listening here?) I've just checked in a fix for 2.13 branch and trunk: I will go back and see if it is busted on 2.12 branch 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.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky8qwwACgkQ+gerLs4ltQ4rZACfTMXqtLPbqmUykbxFiFBORJmy 0BcAn2VqJJWQdDq9jOJXrtn/R9GOD84N =F/tA -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] (re)moving browser subpackage from zc.catalog?
Am 18.10.2010 um 11:02 schrieb Jan-Wijbrand Kolman: > Hi Michael and Marius, > > Thanks for the feedback and suggestions! This is what I did: > > On 10/13/10 15:37 , Michael Howitz wrote: >> Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman: >>> Then there's no real need for a browser extra, as the browser >>> subpackage does not really have any code (only registrations). Or >>> maybe you meant something different? >> >> When someone wants to use the browser package he could use the >> "browser" extra to get all the packages needed for the ZCML >> registrations successfully load. Otherwise he has to find out himself >> where the ZCML directives are declared. > > I created two extra_requires: a browser and a test_browser. The first > lists the dependencies for the browser subpackage to work. The second > for the corresponding tests to run. > > On 10/13/10 14:42 , Marius Gedminas wrote: >> On Wed, Oct 13, 2010 at 01:50:39PM +0200, Jan-Wijbrand Kolman wrote: Ah, no it wouldn't help there, as the testrunner would find the tests in the browser subpackage and it would try to run them regardless. >> You could always conditionally disable them: in each test*.py file >> have >> >> def test_suite(): suite = unittest.TestSuite() if some condition: >>suite.addTest(unittest.makeSuite(...)) >>suite.addTest(doctest.DocTestSuite(...)) >>suite.addTest(doctest.DocFileSuite(...)) return suite > > I also made the tests.py in the browser subpackage only add tests to the > test suite whenever the test_browser dependencies indeed are available. > This fixes the situation where a test runner (in my case the test runner > of the grok toolkit) finds these tests and would try to run them. > > The CHANGES.txt contains instructions on how to enable the ZMI views for > your project in case you need them. > > I propose to release this as 1.5.0, which would be a major version > release that would indicate: "Watch out, potentially backwards > incompatible changes ahead!". > > Right? +1 looks nice. Yours sincerely, -- Michael Howitz · m...@gocept.com · software developer gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 Tests: 38 OK, 3 Failed
On Mon, Oct 18, 2010 at 03:24:10PM +0200, Hanno Schlichting wrote: > On Mon, Oct 18, 2010 at 3:12 PM, Marius Gedminas wrote: > > On Mon, Oct 18, 2010 at 01:58:28PM +0200, Zope Tests Summarizer wrote: > >> Summary of messages to the zope-tests list. > >> Period Sun Oct 17 12:00:00 2010 UTC to Mon Oct 18 12:00:00 2010 UTC. > >> > >> Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 64bit > >> From: ccomb at free.fr > >> Date: Sun Oct 17 22:04:14 EDT 2010 > >> URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021837.html > > > > zope.deprecation fails to find __file__ in f_globals. > > That's a Python 2.4 specific problem. IIRC you simply need to pass in > __file__=__file__ into the globals of the doctest suite (which makes > the __file__ point to the tests.py instead of the doctest.txt file, > but that generally doesn't matter). Thanks! Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development signature.asc Description: Digital 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] Functional areas of Zope
On Mon, Oct 18, 2010 at 8:29 AM, Laurence Rowe wrote: > On 18 October 2010 12:51, Thomas Lotze wrote: ... > I would say that javascript and client side programming frameworks are > out of scope for Zope the project. There are plenty of existing client > side frameworks (jquery, YUI, etc.) with varying degrees of weight and > functionality. We don't want to build another. I agree. The only exception would be if someone came up with something so innovative that we chose to embrace it. I think that the focus of the community should be better leveraging existing libraries. > Zope components may need to implement some rich functionality (form > widgets for instance), in which case it may be worthwhile picking a > particular javascript framework to use (Plone uses jquery). I think it would be counter productive to pick a JS library. We've done some work at ZC on abstracting the JS interface for form generation. See zc.ajax for an early example. (Unfortunately, due to an internal misscommunication here at ZC, that project got forked and recent work has been in our internal repo. We need to move that to the zope repo) The basic idea is that server side "widgets" generate high-level json specifications that can be implemented for different js libraries. A number of people have done work in this area. We should find some forum to compare notes. > We also want to make it easy to communicate between client side > javascript and server side python via JSON (bobo implmented some json > help classes IIRC). So does zc.ajax (and our unfortunately internal zc.ajaxform). These fit better with zope.publisher, fwiw. I'm sure there are other examples of this in the zope ecosystem. Jim -- Jim Fulton ___ 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] Functional areas of Zope
On Mon, Oct 18, 2010 at 7:51 AM, Thomas Lotze wrote: > Hi all, > > at the Zope summit in September, we were talking about what Zope > actually is or should be and how to define the goal of the Zope > project. This led to the idea of identifying the functional areas > of Zope. I don't think that's quite right. I don't remember exactly what we said, but I would hope that we wouldn't contradict the decision, made some time ago that Zope, unless qualified (as in "Zope Community" or "Zope Toolkit"), refers to Zope 2. If we did, it would have been because we were speaking informally. > I'd like to pursue this by starting a discussion about > Zope's functional areas among the developer community and hope to > come up with a number of commonly agreed-upon items. Wherever it > matters, I suggest limiting ourselves to discussing the ZTK in > order to keep things focussed. I think you mean "ZTK" functional areas. Or, perhaps better, Zope Community functional areas. > As functional areas (for some examples, see below), we consider > diverse, broadly defined tasks and problems that a web developer > is being faced with, and that a web framework ought to have an > answer for. We hope to be able to define better what Zope is and > is not and how it compares to other web frameworks by starting > from a set of functional areas and trying to state Zope's answer > to each of them. My opinion, stated at the DZUG, is that Zope is *not* a framework. I think treating it as a framework was an early mistake that has haunted us for years. The ZTK (which we should have had from the beginning) is a collection of frameworks that support Zope the application. > Another benefit from having a grip on functional areas of Zope I'm sorry did you mention benefits above? I dont see them. > the project would be the possibility to organise the large and > grown set of individual packages that make up Zope's code. OK, so a benefit is to organize packages. I guess I can see that. So, a documentation exercise. Perhaps this would be better left to people writing documentation. I have a feeling that some people want to organize community development efforts around these areas, although I don't think you're saying that, although perhaps you hint at that in your summary. ... > - client-side programming framework (no good solution so far, people use > all sorts of Javascript technologies and programming styles) Huh? There are many good client side development libraries. There isn't one obviously "right" javascript library, but there shouldn't be. (I think Tim made a mistake when he included TOOWTDI in the Zen of Python). I'm not going to fault someone for trying to come up with something newer and better, but I don't think it should be a Zope functional area. OTOH, I do agree with Lawrence that there's a lot of value in collaborating on how to integrate existing JS frameworks with the Zope server-side frameworks. Of particular interest to me are: - integrating with form-generation libraries based on zope.schema, - transactional REST interfaces, and - perhaps more direct ZODB data access . > I hope for the discussion to produce a list of functional areas > that most developers agree upon, maybe further areas that need more > consideration, and possibly even some clues about Zope's answers to the > challenges of each functional area. If nothing else, I think the discussion will be valuable. > Thank you very much for your participation. Thanks for spuring discussion. Jim -- Jim Fulton ___ 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 Tests: 38 OK, 3 Failed
On Mon, Oct 18, 2010 at 3:12 PM, Marius Gedminas wrote: > On Mon, Oct 18, 2010 at 01:58:28PM +0200, Zope Tests Summarizer wrote: >> Summary of messages to the zope-tests list. >> Period Sun Oct 17 12:00:00 2010 UTC to Mon Oct 18 12:00:00 2010 UTC. >> >> Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 64bit >> From: ccomb at free.fr >> Date: Sun Oct 17 22:04:14 EDT 2010 >> URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021837.html > > zope.deprecation fails to find __file__ in f_globals. That's a Python 2.4 specific problem. IIRC you simply need to pass in __file__=__file__ into the globals of the doctest suite (which makes the __file__ point to the tests.py instead of the doctest.txt file, but that generally doesn't matter). 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] Zope Tests: 38 OK, 3 Failed
On Mon, Oct 18, 2010 at 01:58:28PM +0200, Zope Tests Summarizer wrote:
> Summary of messages to the zope-tests list.
> Period Sun Oct 17 12:00:00 2010 UTC to Mon Oct 18 12:00:00 2010 UTC.
> There were 41 messages: 6 from Zope Tests, 4 from buildbot at pov.lt,
> 20 from buildbot at winbot.zope.org, 11 from ccomb at free.fr.
>
>
> Test failures
> -
>
> Subject: FAILED : winbot / ztk_10 py_244_win32
> From: buildbot at winbot.zope.org
> Date: Sun Oct 17 17:04:52 EDT 2010
> URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021813.html
zope.testing.testrunner fails in interesting ways.
> Subject: FAILED : winbot / zc_buildout_dev py_244_win32
> From: buildbot at winbot.zope.org
> Date: Sun Oct 17 17:42:19 EDT 2010
> URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021817.html
Extra unexpected output ("Getting distribution for 'foo==1'")
> Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 64bit
> From: ccomb at free.fr
> Date: Sun Oct 17 22:04:14 EDT 2010
> URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021837.html
zope.deprecation fails to find __file__ in f_globals.
Marius Gedminas
--
http://pov.lt/ -- Zope 3/BlueBream consulting and development
signature.asc
Description: Digital 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] Functional areas of Zope
On 18 October 2010 12:51, Thomas Lotze wrote: > Hi all, > > at the Zope summit in September, we were talking about what Zope > actually is or should be and how to define the goal of the Zope > project. This led to the idea of identifying the functional areas > of Zope. I'd like to pursue this by starting a discussion about > Zope's functional areas among the developer community and hope to > come up with a number of commonly agreed-upon items. Wherever it > matters, I suggest limiting ourselves to discussing the ZTK in > order to keep things focussed. > > As functional areas (for some examples, see below), we consider > diverse, broadly defined tasks and problems that a web developer > is being faced with, and that a web framework ought to have an > answer for. We hope to be able to define better what Zope is and > is not and how it compares to other web frameworks by starting > from a set of functional areas and trying to state Zope's answer > to each of them. > > Another benefit from having a grip on functional areas of Zope > the project would be the possibility to organise the large and > grown set of individual packages that make up Zope's code. > > To get the discussion started, I'll give a few random examples of > functional areas that we thought of immediately: > > - software architecture (interfaces, components) > - data persistence (ZODB) > - URL resolution (object traversal) > - form generation (form libs for HTML forms, other possibilities?) > - resource handling (CSS, Javascript delivery) > - client-side programming framework (no good solution so far, people use > all sorts of Javascript technologies and programming styles) I would say that javascript and client side programming frameworks are out of scope for Zope the project. There are plenty of existing client side frameworks (jquery, YUI, etc.) with varying degrees of weight and functionality. We don't want to build another. Zope components may need to implement some rich functionality (form widgets for instance), in which case it may be worthwhile picking a particular javascript framework to use (Plone uses jquery). We also want to make it easy to communicate between client side javascript and server side python via JSON (bobo implmented some json help classes IIRC). Laurence ___ 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: 38 OK, 3 Failed
Summary of messages to the zope-tests list. Period Sun Oct 17 12:00:00 2010 UTC to Mon Oct 18 12:00:00 2010 UTC. There were 41 messages: 6 from Zope Tests, 4 from buildbot at pov.lt, 20 from buildbot at winbot.zope.org, 11 from ccomb at free.fr. Test failures - Subject: FAILED : winbot / ztk_10 py_244_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 17:04:52 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021813.html Subject: FAILED : winbot / zc_buildout_dev py_244_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 17:42:19 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021817.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 64bit From: ccomb at free.fr Date: Sun Oct 17 22:04:14 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021837.html Tests passed OK --- Subject: OK : winbot / ztk_dev py_254_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 16:19:04 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021808.html Subject: OK : winbot / ztk_dev py_265_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 16:27:58 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021809.html Subject: OK : winbot / ztk_dev py_265_win64 From: buildbot at winbot.zope.org Date: Sun Oct 17 16:37:29 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021810.html Subject: OK : winbot / ztk_dev py_270_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 16:46:19 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021811.html Subject: OK : winbot / ztk_dev py_270_win64 From: buildbot at winbot.zope.org Date: Sun Oct 17 16:55:22 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021812.html Subject: OK : winbot / ztk_10 py_254_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 17:13:23 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021814.html Subject: OK : winbot / ztk_10 py_265_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 17:21:22 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021815.html Subject: OK : winbot / ztk_10 py_265_win64 From: buildbot at winbot.zope.org Date: Sun Oct 17 17:29:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021816.html Subject: OK : winbot / zc_buildout_dev py_254_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 17:52:30 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021818.html Subject: OK : winbot / zc_buildout_dev py_265_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 18:03:49 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021819.html Subject: OK : winbot / zc_buildout_dev py_265_win64 From: buildbot at winbot.zope.org Date: Sun Oct 17 18:15:00 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021820.html Subject: OK : winbot / zc_buildout_dev py_270_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 18:26:22 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021821.html Subject: OK : winbot / zc_buildout_dev py_270_win64 From: buildbot at winbot.zope.org Date: Sun Oct 17 18:37:26 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021822.html Subject: OK : winbot / ZODB_dev py_254_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 19:34:27 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021823.html Subject: OK : ZTK 1.0 / Python2.4.6 Linux 64bit From: ccomb at free.fr Date: Sun Oct 17 19:42:13 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021824.html Subject: OK : ZTK 1.0 / Python2.6.5 Linux 64bit From: ccomb at free.fr Date: Sun Oct 17 19:42:44 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021825.html Subject: OK : ZTK 1.0 / Python2.5.5 Linux 64bit From: ccomb at free.fr Date: Sun Oct 17 19:42:56 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021826.html Subject: OK : winbot / ZODB_dev py_265_win32 From: buildbot at winbot.zope.org Date: Sun Oct 17 20:30:53 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021827.html Subject: OK : Zope 3.4 Known Good Set / py2.4-64bit-linux From: buildbot at pov.lt Date: Sun Oct 17 21:10:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021828.html Subject: OK : winbot / ZODB_dev py_265_win64 From: buildbot at winbot.zope.org Date: Sun Oct 17 21:27:34 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021829.html Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sun Oct 17 21:31:14 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021830.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sun Oct 17 21:33:14 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-October/021831.html Subject: OK : Zope-2.12 Python
[Zope-dev] Functional areas of Zope
Hi all, at the Zope summit in September, we were talking about what Zope actually is or should be and how to define the goal of the Zope project. This led to the idea of identifying the functional areas of Zope. I'd like to pursue this by starting a discussion about Zope's functional areas among the developer community and hope to come up with a number of commonly agreed-upon items. Wherever it matters, I suggest limiting ourselves to discussing the ZTK in order to keep things focussed. As functional areas (for some examples, see below), we consider diverse, broadly defined tasks and problems that a web developer is being faced with, and that a web framework ought to have an answer for. We hope to be able to define better what Zope is and is not and how it compares to other web frameworks by starting from a set of functional areas and trying to state Zope's answer to each of them. Another benefit from having a grip on functional areas of Zope the project would be the possibility to organise the large and grown set of individual packages that make up Zope's code. To get the discussion started, I'll give a few random examples of functional areas that we thought of immediately: - software architecture (interfaces, components) - data persistence (ZODB) - URL resolution (object traversal) - form generation (form libs for HTML forms, other possibilities?) - resource handling (CSS, Javascript delivery) - client-side programming framework (no good solution so far, people use all sorts of Javascript technologies and programming styles) I hope for the discussion to produce a list of functional areas that most developers agree upon, maybe further areas that need more consideration, and possibly even some clues about Zope's answers to the challenges of each functional area. Thank you very much for your participation. -- Thomas ___ 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] Moving concrete IAuthenticatorPlugin implementations to zope.pluggableauth
On 10/13/10 18:56 , Michael Howitz wrote: > Am 13.10.2010 um 16:05 schrieb Jan-Wijbrand Kolman: > >> Hi, >> >> A while ago zope.pluggable split off reusable components from >> zope.app.authentication. The concrete IAuthenticatorPlugin >> implementations (principalfolder and groupfolder) however, were left in >> zope.app.authentication. >> >> I think it makes sense to move these IAuthenticatorPlugin >> implementations to zope.pluggableauth.plugins as well, leaving backwards >> compatibility imports and the browser code in zope.app.authentication. >> >> For both packages I created branches [1][2] for working on this. I moved >> the components and made sure the tests pass again. >> >> If there're no objections I'd like to merge these branches to the >> respective trunks and eventually release zope.pluggableauth 1.1.0 and >> zope.app.authentication 3.9.0. > > +1 zope.pluggableauth 1.1 and zope.app.authentication 3.9.0 have been released. Thank you for your feedback. regards, jw ___ 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] (re)moving browser subpackage from zc.catalog?
Hi Michael and Marius, Thanks for the feedback and suggestions! This is what I did: On 10/13/10 15:37 , Michael Howitz wrote: > Am 13.10.2010 um 13:50 schrieb Jan-Wijbrand Kolman: >> Then there's no real need for a browser extra, as the browser >> subpackage does not really have any code (only registrations). Or >> maybe you meant something different? > > When someone wants to use the browser package he could use the > "browser" extra to get all the packages needed for the ZCML > registrations successfully load. Otherwise he has to find out himself > where the ZCML directives are declared. I created two extra_requires: a browser and a test_browser. The first lists the dependencies for the browser subpackage to work. The second for the corresponding tests to run. On 10/13/10 14:42 , Marius Gedminas wrote: > On Wed, Oct 13, 2010 at 01:50:39PM +0200, Jan-Wijbrand Kolman wrote: >>> Ah, no it wouldn't help there, as the testrunner would find the >>> tests in the browser subpackage and it would try to run them >>> regardless. > You could always conditionally disable them: in each test*.py file > have > > def test_suite(): suite = unittest.TestSuite() if some condition: > suite.addTest(unittest.makeSuite(...)) > suite.addTest(doctest.DocTestSuite(...)) > suite.addTest(doctest.DocFileSuite(...)) return suite I also made the tests.py in the browser subpackage only add tests to the test suite whenever the test_browser dependencies indeed are available. This fixes the situation where a test runner (in my case the test runner of the grok toolkit) finds these tests and would try to run them. The CHANGES.txt contains instructions on how to enable the ZMI views for your project in case you need them. I propose to release this as 1.5.0, which would be a major version release that would indicate: "Watch out, potentially backwards incompatible changes ahead!". Right? Thanks again for your feedback! kind regards, jw ___ 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 )
