-----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-----