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
Am 25.04.2010, 11:14 Uhr, schrieb Christophe Combelles <ccomb@free.fr>:
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
Hi. On Sun, Apr 25, 2010 at 11:14 AM, Christophe Combelles <ccomb@free.fr> 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
Hanno Schlichting a écrit :
Hi.
On Sun, Apr 25, 2010 at 11:14 AM, Christophe Combelles <ccomb@free.fr> 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
-----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 tseaver@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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
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.
I'm attaching a brief overview of the various ZTK and zopeapp package sets, showing how they are used by the variouss downstream projects. This analysis is based on current checkouts of each of Zope2, Grok, and Bluebream. - - "Direct" dependencies are mentioned in the setup.py (of the generated project for BlueBream). - - "Transitive" usage is computed by loading the working set inside the custom interpreter after running each buildout, e.g.: $ bin/grokpy ...
from pkg_resources import working_set from pprint import pprint pprint(sorted([x.project_name for x in working_set])) ...
A couple of observations: - - There is a sizable subset of the ZTK list which is actually used by all three downstream projects. These packages are likeliest to stay healthy. - - There is another big subset of the ZTK list shared by Grok and Bluebream, but not Zope2, which makes sense given their common ancestry. - - Many of these packages are used only as transitive dependencies; such packages become more likely to bitrot, I think. It is possible that the downstream packages don't explicitly list dependencies for code they import directly: if that is true, we should fix them. - - Each downstream project has a small subset of the ZTK list which only it uses. These packages should perhaps move from the ZTK orbit into the orbit of the interested project. Note that I'm not sure about a couple of the Grok-only projects (e.g., the catalog-related ones): they may be missing from the BlueBream column simply because the project generated by BlueBream doesn't do cataloguing. - - There are ZTK packages which are not used by any downstream project (zope.documenttemplate, zope.html, zope.mimetype, zope.ramcache) These packages should drop out of the ZTK, unless I have overlooked real usage. There is a fourth column which I have no way to tabulate, which is "classic Zope3" applications which have been updated to track the ZTK versions. Obviously the folks who are maintaining those applications have a stake in the health of the packages they use. I believe that we need to be looking for explicit maintainers for the projects which narrower usage across the downstream projects. I don't know exactly what this process would look like: one low-tech approach would be to add a MAINTAINERS.txt file to each project with the names of the developers or downstream projects who care for the project. Any other thoughts? Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@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 iEYEARECAAYFAkvUpM4ACgkQ+gerLs4ltQ6jFgCdGFojqifKMZ2e+4Hoji7vtsSq DlgAn1m8UIrAkULAwOpki6pkC5eOy5QX =0KO5 -----END PGP SIGNATURE-----
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
-----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 tseaver@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-----
Hi there, Tres Seaver wrote:
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).
Okay, that should be approximately 1.1.
and the following further packages say that they are marked as unused, according to the dependency checker:
- - zope.app.appsetup
This is definitely being used. I figure it's a dependency through ZCML.
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?
Yes. We'll likely have a grok-backwards package or something like that that depends on the "lost" dependencies, so a developer can depend on that with their project. Regards, Martijn
participants (5)
-
Charlie Clark -
Christophe Combelles -
Hanno Schlichting -
Martijn Faassen -
Tres Seaver