[Zope-dev] Re: [Plone-developers] zcml entry points

[Martijn Faassen]

Hello,

On 10/24/07, Chris McDonough <chrism at plope.com> wrote:
[snip]
> I think maybe more abstractly, it might be useful to think about
> separating based on libraries vs. applications.  Libraries should be
> as policy-free as possible (otherwise they're not libraries, they're
> applications).  Applications, however, must declare policies (or they
> would be useless, this is what makes them applications [sorry for the
> reflexive tautology]), but this makes them not useful outside of some
> context.  If a library egg contains an entry point that either loaded
> or returned a stream for the moral equivalent of meta.zcml, that
> would be fine.  But it would be less OK for an egg which represented
> a library's ZCML to contain adapter and utlity registrations.
> However, if the egg represented an application, it would be fine for
> it to do either.

I am not sure I see such a hard distinction between applications and
libraries myself, at least not on the boundary of adapter and utility
registrations. I think in many cases libraries provide default
implementations of adapters, for instance, and default global utility
registrations. This makes the library more easy to use without having
to do extra work, if at least the defaults apply to your work. You may
of course have to override the default behavior, by registering an
adapter for a more specific interface or class, or by registering a
local utility.

Take a library that registers views (multi adapters) as widgets for
form fields, for instance. Do you consider this to be an
application-like library? I consider this to be a library.

> Zope 2 'Products' are usually applications in a sense, because they
> are *never* useful outside the context of Zope-the-application-
> server, and that's why Five's automagical load of "meta",
> "configure", and "overrides" ZCML is completely appropriate for them,
> and why it would make sense, if products became eggs, to have all of
> their ZCML loaded at Zope startup time.

I can see where you're coming from, but you are stretching the
terminology to its breaking point, though. I really don't consider
XMLWidgets or ParsedXML to be *applications*. I don't even consider
Formulator to be one. We have to look at their intent. Their intent is
to provide components that can be reused to create applications. If
anything, that mean they're libraries (that provide components).
They're libraries highly coupled to Zope 2, of course. Zope 2 isn't
designed with loosely coupled libraries in mind. It's not great. But
to go calling these 'applications' I think might cause a lot of
confusion in terminology. I'd like us to come up with better words to
describe heavily-coupled versus loosely-coupled, and policy-heavy
versus policy-light or policy-free.

[snip]

> We don't really complain too badly right now that setuptools doesn't
> infer all of our dependencies for us from import statements in the
> packages it contains in order to prevent us from having to manually
> specify dependencies in our setup.py.

We might not, but this one has been in the back of my mind for a
while. I'd like to be able to write code where I just import
something, and poof, it's there. Of course such automation can be
dangerous, but hopefully it could be tamed. With Zope we add a third
structure to it: ZCML dependencies, and while two places may be an
accident, three places definitely calls for some thinking about don't
repeat yourself.

Again, I see your points. I think it makes sense for libraries to be
light on policy. It's also clear that for instance ZMI views are too
much policy one gets with a typical Zope 3 library. I don't think we
should however consider all libraries that register a few adapters as
'policy heavy'. Once we take the ZMI registrations out, is what is
left policy-heavy or policy-light?

Regards,

Martijn