[Zope-dev] Dependencies for ZCML

[Martijn Faassen]

Tres Seaver wrote:
[snip]
> Please don't put words in my mouth.  I *do* care that the
> "mega-frameworks" succeed. 

My apologies, I got this impression because you very much want to frame 
the debate in terms of libraries, but I understand that is also a way to 
  try to improve the whole.

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

I agree that going into a more library-like direction makes sense. I 
have caveats as I can think of packages that behave like libraries from 
one perspective but like frameworks from another. But I do agree we 
should look into getting more library-like reuse out of our packages.

[snip]

Here you sketch out a program:

> 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'm for such a program in principle.

We can't do it in one big step; we'll have to review each package and 
rewrite tests and do it bit by bit and see where it makes sense and what 
issues we run into. We also very much don't want these ZCML packages to 
be like zope.app.zcmlfiles, which is cluttering up the dependency works.

I'll add again my caveat about losing abstraction if all test writers 
have to use fairly low level component configuration for some high-level 
registrations, and we require such knowledge from the writers of tests.

I wish there were a higher-level API that could be used to do common 
registrations for views, subscribers, etc. Especially views can be 
configured in non-trivial ways by browser:page and I'm worried people 
will need to learn a bit much about the details of this. We should 
simplify that of course. But in general I have a concern about losing an 
abstraction layer. I wish we had some form of answer to this.

With grokcore.component, you can in your tests simply decide to "grok" a 
class or not to configure it. If that class is a 
grokcore.component.Adapter (for instance), it'll be registered. This 
introduces a dependency on grokcore.component. This would add a 
dependency everywhere but it is higher level. Once the dependencies for 
grokcore.view are rooted out, you could do the same for views.

I'm not proposing we rewrite all code to use grokcore.component or 
grokcore.view; I'm just indicating that having an easy way to register a 
component can be easy.

But that shouldn't block the effort; I'm sure many packages that use 
ZCML in their tests can be rewritten today to use zope.component 
registrations in their tests without too much effort and if people want 
to do that, we should go ahead.

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

What I'm trying to get across is that besides positions we need a way 
forward to improve the situation. This approach isn't obvious to all of 
us, you know. :) You started out sketching such an approach, and that's 
good.

I think a next step is to try modifying a package in the way you 
envision and discuss the consequences and results here. We'd need a 
place to store the ZCML that's pulled out too.

Thanks for sticking with it!

Regards,

Martijn