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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martijn Faassen wrote:
> 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.

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.

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

Maybe we need to add a term, 'plugin', to describe things like Zope2
products which register only "behavior" and not "addable applications."
 The line gets fuzzy here, too:  PAS uses 'plugin' to describe an object
which is added to a persistent user folder, and then configured to
perform one or more roles in its framework.  Oooh, there's another term,
'framework'.  In my mind, 'frameworks' declare interfaces for 'plugins'
to supply.  OTOH, 'frameworks' don't want every possible plugin to be
magicdally configured:  they are all about explicit configuration.

Plone makes configuring QuickInstaller-enabled products explicit:  the
site manager gets to choose at runtime (not at startup), and can change
her mind later.  In that sense, Plone is 'framework'-like, rather than
'application'-like.

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

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.

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



Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHH1/s+gerLs4ltQ4RAgt6AKCBcNbbVuL+uAsE/14ObFGFlKcIIQCeOZb9
hUXK73WjzcnHekVR7iGnKMU=
=Lz7n
-----END PGP SIGNATURE-----