-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
Hey,
Tres Seaver wrote: [snip]
Doesn't that in some cases make tests harder to understand, as lower-level APIs are in use that are not as recognizable as the equivalent ZCML directives? (say, registering an event) Don't we place a burden on the test writers to learn these APIs while they could use the ones abstracted away behind ZCML instead? No. Relying on "real" ZCML in testing, as is using the "real" components is an anti-pattern: it makes tests fragile, couples the packages tightly, etc.
Huh? You can't be serious saying there is not extra burden on the test developers if you require them to learn about the implementation of various ZCML directives in order to write a test. The burden is in learning how a view is registered, or how a subscriber is registered, in order to write a test. You need them to break through the abstraction that ZCML provides in order to write a test. It will also make it harder to read the tests as the reader will need to share this understanding as well.
You can't just go and say it's an anti-pattern without giving an alternative, otherwise people will continue to use the higher-level of abstraction for registration (i.e. ZCML).
The alternative is that developers use 'zope.component.provide*' rather than loading ZCML. The upsides are: - - They can register stub implementations, some of which may not even be "importable" (e.g., local closures). - - They can avoid testing dependencies on 'zope.configuration' and friends. - - The tests run faster. - - The tests run "cleaner".
[snip]
I don't think "library" packages have ZCML in them at all, except as examples, because trying to reusing ZCML doesn't actually win unambiguosly over copying it.
Here's my position on this:
You take a hard-line purist opinion. We may want to take an attitude like this for the Zope Framework libraries, eventually. We cannot just do this by throwing out all ZCML from our packages.
Why not? Because the Zope community is in the business of providing an integrated experience too (Zope 2, Zope 3 and Grok), like it or not. (hold on, I know you don't care about this. I'm getting to this)
This means that we, as a community on zope-dev care about configuration (no matter where it is maintained). Since we do, we should maintain and test it. Since we're a community and care about compatibility it's good to share the burden of maintaining and distributing this configuration, instead of just ignoring this and deferring it to the individual projects.
Today, the "shared configuration" project is scattered over the individual packages in individual zcml files that refer to each other. If we want this project elsewhere, we need to take realistic, active evolutionary steps to get there, package by package. We can't just drop the ball on this, as we have projects depending on this information.
I know you don't care one bit about such projects yourself. You just care about the libraries.
Please don't put words in my mouth. I *do* care that the "mega-frameworks" succeed. However, I don't think that "blessing" the current usage is going to help them succeed in the long run. I think that moving the "shared configuration" bits out of "library" packages ought to be a fairly high-priority, near-term goal, in order to increase the quality / reusability of the "library" packages, which will also increase the quality / stability of the mega-frameworks, and reduce the burden of maintaining both. I think the tight coupling of "scattered + required" ZCML has turned out to be a net loss over time, because it forces people to make an "all-or-nothing" choice about adopting "Zope" early on in their evaluation. Making it attracive and easy to use pieces of Zope, while deferring that "all-in bet," is a big driver for the "purism" you are describing.
Fine, but you'll have to acknowledge that other people *do* care about this project. They have frameworks and applications to maintain that need the configuration scattered through the Zope Framework code base right now.
I'll draw a semantic distinction, based on the grammatical ambiguity in that sentence: those applications "need the configuration", but they don't "need the configuration to be scattered through the code base", except for BBB purposes. For instance, if we provided for each mega-framework a single "everything {Grok,Zope2,Zope3ZMI} needs from the Zope framework" package, which named all the appropriate dependencies *and* provided the "shared" ZCML, and then switched each mega-framework and its applications to use that package, we could remove the ZCML from all the other packages (except for BBB). In fact that single package would *be* the mega-framework at that point. Once we had such packages, we could look at whether factoring out some of the common dependencies / ZCML from each of them into one or more shared "Zope Framework ZCML" package would be worthwhile. The choice to do such a refactoring would be transparent to existing applications built on the mega-frameworks. New applications might choose to target one or more of the "subset" packages, or not.
I've heard your purist opinions in this area before. It's not very helpful in the way presented. If you want us to buy into your opinions you'll have to make them more attractive to us, and you know about our concerns as a community.
Hmm, I'm not sure how to reply to that. I'll keep trying to clarify my positions, including removing any unintended "heat", and supplying any extra considerations to address your concerns. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJvoTu+gerLs4ltQ4RAv9MAJ94Tl2cMkOsClBJ5aCnPI/rvwrN6wCg2QZD BGuGDkLMp70Z9/j8JqhYcyI= =f9LF -----END PGP SIGNATURE-----