[Zope-dev] ZTK community packages
Hi! I believe packages such as z3c.form, z3c.macro, z3c.template, z3c.pagelet (and many others) are among the most important packages. I wonder why they are not included in the ZTK? I always end up using them, I believe they should even be part of the core ZTK. If they are not part of the core, I would like them to be part of a *community.cfg* list. There already is a community.cfg list in BlueBream, but I don't like having many foobartoolkit in the wild, with many package lists to maintain. It's already difficult enough to maintain just 1 list for the zopetoolkit. Let's focus on it. regards, 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 )
Re: [Zope-dev] ZTK community packages
Am 25.04.2010, 11:14 Uhr, schrieb Christophe Combelles : > Hi! > I believe packages such as z3c.form, z3c.macro, z3c.template, > z3c.pagelet (and > many others) are among the most important packages. I wonder why they > are not > included in the ZTK? I always end up using them, I believe they should > even be > part of the core ZTK. > If they are not part of the core, I would like them to be part of a > *community.cfg* list. There already is a community.cfg list in > BlueBream, but I > don't like having many foobartoolkit in the wild, with many package > lists to > maintain. It's already difficult enough I wonder how much is just to with the namespace (and possibly licence) and how much has to do with competing with other parts of the ZTK, ie. z3c.form with zope.formlib but only in the maintenance can be kept within the ZTK. But surely we want to reduce the number of packages in the ZTK? Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 ___ 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] ZTK community packages
Hi. On Sun, Apr 25, 2010 at 11:14 AM, Christophe Combelles wrote: > I believe packages such as z3c.form, z3c.macro, z3c.template, z3c.pagelet (and > many others) are among the most important packages. I wonder why they are not > included in the ZTK? I always end up using them, I believe they should even be > part of the core ZTK. We have written down some definition of what constitues a core library at http://docs.zope.org/zopetoolkit/about/coreextra.html. That document is outdated to some degree, and likely the "steering group" should now be replaced by the "release team". Nevertheless the criteria given in that document are still sensible in my opinion. z3c.form might at some point become part of the ZTK. But right now none of the major projects includes it in its core. The other z3c libraries you mention, I have never heard of or wouldn't know what they did. They sound to me related to a specific way of constructing user interface related code. I think there's many different approaches to that and only very few can claim to be used by multiple of the major projects. > If they are not part of the core, I would like them to be part of a > *community.cfg* list. There already is a community.cfg list in BlueBream, but > I > don't like having many foobartoolkit in the wild, with many package lists to > maintain. It's already difficult enough to maintain just 1 list for the > zopetoolkit. Let's focus on it. What you are describing is similar to the idea of the "extra" concept we have defined for the ZTK. It has at this stage no manifestation in any code, version list or process around it. At this stage I would prefer to focus on the ZTK as a least-common-denominator of the major projects. And only if we are actually able to agree on such a set, should we try to extend it. This is going to be hard enough and extending the set of packages won't make it any easier. That doesn't mean you shouldn't go forward with your idea. I just like to have it separate from the ZTK. 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 )
[Zope-dev] Zope Tests: 10 OK, 6 Failed
Summary of messages to the zope-tests list. Period Sat Apr 24 12:00:00 2010 UTC to Sun Apr 25 12:00:00 2010 UTC. There were 16 messages: 6 from Zope Tests, 9 from ccomb at free.fr, 1 from ct at gocept.com. Test failures - Subject: FAILED: Repository policy check found errors in 670 projects From: ct at gocept.com Date: Sat Apr 24 21:16:22 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014097.html Subject: FAILED : ZTK 1.0dev / Python2.5.2 Linux 32bit From: ccomb at free.fr Date: Sat Apr 24 23:13:51 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014108.html Subject: FAILED : ZTK 1.0dev / Python2.4.6 Linux 32bit From: ccomb at free.fr Date: Sat Apr 24 23:14:22 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014109.html Subject: FAILED : ZTK 1.0dev / Python2.6.4 Linux 32bit From: ccomb at free.fr Date: Sat Apr 24 23:14:27 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014110.html Subject: FAILED : Zope 3.4.1 KGS / Python2.4.6 32bit linux From: ccomb at free.fr Date: Sun Apr 25 00:22:15 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014111.html Subject: FAILED : Zope 3.4.1 KGS / Python2.5.2 32bit linux From: ccomb at free.fr Date: Sun Apr 25 00:56:48 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014112.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Sat Apr 24 21:39:47 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014098.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Sat Apr 24 21:41:49 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014099.html Subject: OK : Zope-2.12 Python-2.6.4 : Linux From: Zope Tests Date: Sat Apr 24 21:43:51 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014100.html Subject: OK : Zope-2.12-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Apr 24 21:45:51 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014101.html Subject: OK : Zope-trunk Python-2.6.4 : Linux From: Zope Tests Date: Sat Apr 24 21:47:51 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014102.html Subject: OK : Zope-trunk-alltests Python-2.6.4 : Linux From: Zope Tests Date: Sat Apr 24 21:49:57 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014103.html Subject: OK : BlueBream template / Python2.6.4 32bit linux From: ccomb at free.fr Date: Sat Apr 24 22:00:51 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014104.html Subject: OK : BlueBream template / Python2.7b1 32bit linux From: ccomb at free.fr Date: Sat Apr 24 22:00:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014105.html Subject: OK : BlueBream template / Python2.5.2 32bit linux From: ccomb at free.fr Date: Sat Apr 24 22:00:54 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014106.html Subject: OK : BlueBream template / Python2.4.6 32bit linux From: ccomb at free.fr Date: Sat Apr 24 22:00:55 EDT 2010 URL: http://mail.zope.org/pipermail/zope-tests/2010-April/014107.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] ZTK community packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christophe Combelles wrote: > Hi! > > I believe packages such as z3c.form, z3c.macro, z3c.template, z3c.pagelet > (and > many others) are among the most important packages. I wonder why they are not > included in the ZTK? I always end up using them, I believe they should even > be > part of the core ZTK. > > If they are not part of the core, I would like them to be part of a > *community.cfg* list. There already is a community.cfg list in BlueBream, but > I > don't like having many foobartoolkit in the wild, with many package lists to > maintain. It's already difficult enough to maintain just 1 list for the > zopetoolkit. Let's focus on it. "Clumping" vs. "splitting" debates are endless, in many fields. In the case of the ZTK, we have tried to say that the "core" toolkit consists only of packages in wide use by more than one of the "constituent" communities: any package which doesn't meet that criterion should just be managed by the community which already cares for it. If that community organizes automated testing for it package set(s), and publishes results (especially failures) for those packages when used with the core, then the broader communitiy has proved willing to work to resolve those problems. 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 iEYEARECAAYFAkvUfA0ACgkQ+gerLs4ltQ5X/gCg3Jf9Oin+5Yd1cuHvhaS/1wym HdEAoJByL29os3zgiEdXxfDeONs6Rqzo =WqDL -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] ZTK community packages
Hey, Interesting, and thanks for doing this. Concerning Grok, did you look at Grok 1.0 or Grok 1.1? For Grok 1.2 we've identified that the following zope.app packages are certainly used: * zope.app.wsgi * zope.app.appsetup * zope.app.publication We've eliminated the dependencies of these packages on zope.app.testing and zope.app.zcmlfiles, which both pull in a lot of zope.app.* stuff. We've expanded zope.app.wsgi so we can run functional tests and testbrowser tests without zope.app.testing involved; see zope.app.wsgi.testlayer. We're in the process for Grok 1.2 to try to reduce Grok's dependencies to this subset. The grokcore.* packages already eliminate the zope.app.zcmlfiles and zope.app.testing dependencies (in the proper development branches), but as of yesterday Grok itself only eliminates the zope.app.testing dependency so far - zope.app.zcmlfiles is next. We expect more zope.app.* packages than the ones above will be needed to actually run Grok; we don't quite know which ones yet, and we'll be looking at them on a case by case basis. Of course we'll also need the other zope.app.* packages for a while longer to provide backward compatibility imports and such for those upgrading existing Grok apps. Regards, Martijn ___ 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] ZTK community packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: > Interesting, and thanks for doing this. Concerning Grok, did you look at > Grok 1.0 or Grok 1.1? Just grok/trunk (I was trying to think about the "state of ZTK" in terms of how it was being used by latest-and-greatest versions of downstream projects). > For Grok 1.2 we've identified that the following zope.app packages are > certainly used: > > * zope.app.wsgi > > * zope.app.appsetup > > * zope.app.publication On the grok trunk, the following zope.app packages are called "unconditionally" out in grok's setup.py[1]: - - zope.app.publication - - zope.app.publisher - - zope.app.renderer - - zope.app.zcmlfiles and the following further packages say that they are marked as unused, according to the dependency checker: - - zope.app.appsetup - - zope.app.pagetemplate - - zope.app.security - - zope.app.twisted The other zopeapp packages marked for Grok are all transitive dependencies of something else. [1] svn.zope.org/*checkout*/grok/trunk/setup.py > We've eliminated the dependencies of these packages on zope.app.testing > and zope.app.zcmlfiles, which both pull in a lot of zope.app.* stuff. Cool. > We've expanded zope.app.wsgi so we can run functional tests and > testbrowser tests without zope.app.testing involved; see > zope.app.wsgi.testlayer. Really cool. > We're in the process for Grok 1.2 to try to reduce Grok's dependencies > to this subset. The grokcore.* packages already eliminate the > zope.app.zcmlfiles and zope.app.testing dependencies (in the proper > development branches), but as of yesterday Grok itself only eliminates > the zope.app.testing dependency so far - zope.app.zcmlfiles is next. > > We expect more zope.app.* packages than the ones above will be needed to > actually run Grok; we don't quite know which ones yet, and we'll be > looking at them on a case by case basis. I would advocate that such packages be listed explicitly in setup.py, even if you know that right now they would be pulled in as transitive dependencies. > Of course we'll also need the other zope.app.* packages for a while > longer to provide backward compatibility imports and such for those > upgrading existing Grok apps. I'm assuming that BBB imports could be "soft" dependencies, and that developers who are upgrading from earlier Grok versions can adjust their own buildouts or package depenencies to pull the extras in without Grok needing to provide "convenience dependencies" -- am I right? 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 iEYEARECAAYFAkvUw2QACgkQ+gerLs4ltQ7F3ACbBsmHh/tZ/oB9NPgqHIChBv7w yHAAn37Q1MvszPiFZYcN452pHiKYqJI5 =JeNH -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] ZTK community packages
Hanno Schlichting a écrit : > Hi. > > On Sun, Apr 25, 2010 at 11:14 AM, Christophe Combelles wrote: >> I believe packages such as z3c.form, z3c.macro, z3c.template, z3c.pagelet >> (and >> many others) are among the most important packages. I wonder why they are not >> included in the ZTK? I always end up using them, I believe they should even >> be >> part of the core ZTK. > > We have written down some definition of what constitues a core library > at http://docs.zope.org/zopetoolkit/about/coreextra.html. That > document is outdated to some degree, and likely the "steering group" > should now be replaced by the "release team". I understand the principle of "extra" packages. They are not part of the core, but they use the core, and they may be part of the core in the future. That's a good thing, but looking at the zopetoolkit package, there is no such list yet. I really think we should track such packages in an "extra.cfg" file. I think it has some advantages for everyone: For the extra packages: - they can benefit from the buildbot infrastructure - it increases their visibility - it encourages their maintainers to support and release new versions - they can more easily find a place in the large version set of all packages For the core: - it gives an easy access to many more third-party tests that can help find bugs in the ztk core or improve it. - it helps selecting future candidates for inclusion in the core > > Nevertheless the criteria given in that document are still sensible in > my opinion. z3c.form might at some point become part of the ZTK. But > right now none of the major projects includes it in its core. The Regarding z3c.form, it will be at least part of Plone, via the Dexterity content type library. And I suppose that many zope 3 projects are using it. > other z3c libraries you mention, I have never heard of or wouldn't > know what they did. They sound to me related to a specific way of > constructing user interface related code. I think there's many > different approaches to that and only very few can claim to be used by > multiple of the major projects. z3c.pagelet is the best way I've seen to create really redistributable browser page templates, because they are not linked to any macro or master template. They basically are both browser pages and content providers, and they can choose themselves their content template and layout template from bottom up. Among other advantages, they benefit from the 2-way update/render pattern of the content providers or viewlets. z3c.macro is an easy way to register macros in zcml, then use it with use-macro="macro:somemacro" without the burden of creating a view dedicated to macro retrieval. z3c.template can make content templates and layout templates context-dependent. They are registered separately from the views. Not mentionning z3c.formjs, which is a good jquery-based library on top of z3c.form to create javascript-enabled forms. > >> If they are not part of the core, I would like them to be part of a >> *community.cfg* list. There already is a community.cfg list in BlueBream, >> but I >> don't like having many foobartoolkit in the wild, with many package lists to >> maintain. It's already difficult enough to maintain just 1 list for the >> zopetoolkit. Let's focus on it. > > What you are describing is similar to the idea of the "extra" concept > we have defined for the ZTK. It has at this stage no manifestation in > any code, version list or process around it. Ah ok, if this is already defined, but just missing an implementation, I will help with implementing it. > > At this stage I would prefer to focus on the ZTK as a > least-common-denominator of the major projects. And only if we are > actually able to agree on such a set, should we try to extend it. This > is going to be hard enough and extending the set of packages won't > make it any easier. Sure, it should not block or even delay the ZTK release. We can even release a ZTK with failing tests on the extra packages. I'm confident that these failures will be fixed much quicker in they are visible to everyone ;) Christophe > > That doesn't mean you shouldn't go forward with your idea. I just like > to have it separate from the ZTK. > > 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 )
