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

[Martijn Faassen]

Hey,

On 10/24/07, Tres Seaver <tseaver at palladion.com> wrote:
> Martijn Faassen wrote:
[snip]
> > 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.
>
> I can see that.  I still don't want its view registrations automagically
> included in my configuration.  If it exposes an entry point signalling
> that it is a plugin for the specific application I'm running, that would
> be different.

I propose below to classify these entry points not by application but
by type. You'll almost have to otherwise you'll end up touching quite
a few libraries for each framework or pluggable application that gets
written, right?

> The 'pkg_resources.require' function lets you spell your dependency
> before you import;  you'd still have to import whatever names you wanted
> from the distribution, but you could be naming both in the same module.

Right, I did read what you pointed out elsewhere in this discussion.
Thanks for pointing that out. It bears some investigation.

I am wondering whether we can make some buildout recipe that, together
with a database of what distributions provide which imports, can
determine what to fetch and bake it into the setup.py of the package
under development. Together with a 'known good versions' system it
could even fetch a reasonable version.

> > 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?
>
> I don't want to have to override *any* policy imposed by a library,
> unless I specifically choose to enable that policy in the first place.

Sure, but one person's policy is another person's behavior. :) I
disagree with the position that should not ever treat an adapter
registration as an implementation detail to provide some default
behavior. Sometimes the behavior of a library *relies* on certain
adapters being registered. An example is an adapter registration to
generate an appropriate error message (if no more specific adapters
are registered by the user of the library).

Anyway, I think we're mostly going round and round. Currently we're
debating what the entry point means that says "load the basic ZCML".
So perhaps we need a "minimum ZCML" and "convenient defaults ZCML"
entry point, which may be one and the same in some cases. A framework
can then choose to load convenient defaults by default, or absolute
minimum stuff by default. To get started we should pick one entry
point - if someone finds it loads too much policy we can add another
one, or if someone finds it loads too little, likewise.

Regards,

Martijn