[Zope-dev] Re: zcml entry points

[Martin Aspeli]

Tres Seaver wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martijn Faassen wrote:
>> Tres Seaver wrote:
>>> Wichert Akkerman wrote:
>> [snip]
>>>> So I turned things around: if I state in my egg information that I
>>>> require another package that means I need to have that package
>>>> available and functional. Which suggests that its zcml has to be loaded
>>>> before mine. And that is exactly what I am doing: adding an entry point
>>>> that allows a package to say "in order to function I need to have these
>>>> zcml files loaded".
>>> I may not *want* the other package's ZCML to be loaded:  some of its
>>> policies may not be appropriate for my application.  
>> Since this appears to be a rare case that is the exception, what about 
>> using the new ZCML exclude framework for this case? You need to know 
>> what you are doing, but this use case is for people who know exactly 
>> what they're doing anyway, right?
> 
> It isn't that rare:  how many people want to turn off the Rotterdam skin
> in Z3, for instance?  In general, the authors of a "library" package
> can't anticipate how their code will be used;  the ZCML they provide is
> intended to cover the cases they know or imagine most people want.

That probably depends a bit on how that package is created though. In an 
ideal world, Rotterdam would be a separate package (or packages) that 
could be pulled in or not (i.e. if you don't depend on it and/or you 
don't include its ZCML file and/or you use the zc.configure exclude 
behaviour to turn it off).

> ZCML represents policy, not mechanism, and hence is inherently less
> reusable than code.

That is true, but how many people actually re-do all the ZCML for all 
the packages they use? Most packages, I imagine, will have been built 
with re-use in mind. They make appropriate use of adapters and marker 
interfaces and whatever else so that the user of the package has some 
control, or even an opt-out. But for most packages, I don't think 
there's going to be a host of different policies that are actually 
interesting.

Put differently, in Plone we choose not to include various packages, but 
the ones we *do* use, we tend to use wholesale. We may override (or use 
a more-specific adapter for) some policy decisions, e.g. when it was 
written for zope 3 and we need some zope 2 magic, but up until now 
that's tended to be pretty manageable.

I fully subscribe to the separation of policy and implementation (though 
I think in practice, "policy" is often something you override with 
specific adapters or utilities, not only expressed in ZCML), but I 
really hope that most Zope 3 developers don't end up reading, 
understanding and may reproducing every single line of ZCML in every 
single package they ever depend on. :)

I think Jim's suggestion was good, though: Something like Plone or Grok 
- that want to be "pluggable applications" - could use an 
<includeEntryPoints /> type ZCML directive to process ZCML pulled in via 
entry points. Other packages may choose not to do that. Other packages 
again, may choose to do that but then use zc.configure to turn some 
stuff off, or just override whatever registrations they need.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book