[Zope-dev] the Zope Framework project

[Chris McDonough]

Martin Aspeli wrote:
> Chris McDonough wrote:
> 
>> Sorry, the "you" above in "you scolded" was Martin Aspeli, not Faassen.
> 
> Note that the "scolding" had something to do with you breaking Plone 
> trunk due to a transitive change in Chameleon, and the realisation that 
> from this point on, any package shared between repoze.bfg and Plone (or 
> anything else) that is configured with ZCML, will probably need to be 
> forked. We found a workaround with Chameleon, but not one that will scale.

The fix is totally scalable and completely correct.  Chameleon.zpt just does not
have any (real) ZCML anymore.  Any package that has ZCML is, by definition,
written for some framework as stuff that is meant to be overridden, otherwise it
wouldn't be written as configuration.  ZCML is unlike code in this way.  If it
wasn't meant to be overridden, it would be in code.

All packages which are meant to be maximally useful outside the scope of that
framework should be split into two things: the library portion, then some
portion that contains ZCML for gluing in to some framework that wants ZCML in
some specific configuration.  So currently a glue package (five.pt) contains the
ZCML that makes Chameleon work under Plone.  All we did was remove the ZCML from
chameleon.zpt itself and make some other package responsible for configuring the
CA components used by chameleon.zpt.  Frameworks that don't use ZCML don't even
need to do this; they just import stuff.

> The other cause for frustration was that you'd basically discounted all 
> possibility of doing this at the zope.component level (and thus letting 
> others benefit - Zope 2, Five and Plone needs rid of the zope.security 
> dependency too) before you'd even tried. However, I didn't know then 
> quite how disillusioned you were with Zope, or that you were quite so 
> willing to maintain forks/spin-offs/re-implementations under the Repoze 
> brand.

How is the current situation where chameleon.zpt just has no ZCML not 100%
exactly the right thing?  And again, why can't Plone and Zope 2 just use
repoze.zcml in reality?  Why would this not work?  I just don't understand.

>>> And you think it's all due to the brand...
>> Yes!  Someone who *wants* to use basic ZCML directives but doesn't want
>> zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and
>> pytz can *already* use repoze.zcml; the only thing they don't get here is the brand.
> 
> At least when the change was made to Chameleon, it caused 
> incompatibilities that basically broke another application using 
> zope.component's versions of these directives. I'm sure those could be 
> resolved (and were, with a workaround, in Chameleon), but it caused a 
> fair bit of pain.

How could it have?  The only difference was that the package stopped including
the two ZCML utility declarations and you had to configure them independently.
That was hard?  What promises could possibly have been made to Plone that those
declarations would exist exactly in the place they were previously until the end
of time?  If working around that particular problem was at all hard, or caused
any pain, we've got huge problems because people *completely* misunderstand the
purpose of ZCML and configuration in general.

> But more importantly, there are lots of people using Zope the platform, 
> who have the same types of problems. For Zope 2 or Five or Plone to 
> switch wholesale to repoze.zcml is probably going to be impossible, for 
> documentation-related, practical and technical reasons.

Sounds pretty handwavy.  I am particularly suspect of these practical reasons;
they just don't need to exist.

I suspect my only crime here is that I didn't do it "the way its done" (nicely,
with lots of maillist chatter, over the course of weeks); if I had, the outcome
would have been the same: a package that offered ZCML component registration
handlers that doesn't rely on zope.security.  It might have been named
"zope.foo" rather than "repoze.foo".  But the outcome would have been exactly
the same.  There is no way to change zope.component and get both b/w compat and
no dependence on zope.security.  This is still true.

Note that there's some misguided idea that repoze.zcml has "magic" in it for
dealing with multiregistries and WSGI or somesuch; this is not true.  It knows
nothing of either; all it does is implement "utility", "adapter", and the
"subscriber" directives without security-related attributes.

> By forking 
> without attempting to solve the problem at the framework level, the 
> chance for collaboration and shared effort is lost.

There is no loss here.  At very worst, if folks are unwilling to actually just
*use* the package, there is a blueprint for some merge into zope.component that
does not require security stuff.  Once there's enough political will to actually
*do* the merge, and tell the people who want the security stuff that they'll
need to lose (or at least change code), putting the code in is cutnpaste.  I
fail to see how this is any sort of problem at all.

- C