[Zope-dev] Dependencies for ZCML

[Tres Seaver]

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