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

[Chris McDonough]

On Oct 22, 2007, at 11:46 AM, Lennart Regebro wrote:

> On 10/22/07, Martijn Faassen <faassen at startifact.com> wrote:
>> In at least 3 places we express dependency information. For different
>> *purposes* in each case, but we still state something like:
>>
>> 1. "we use dependency X, and please download and install it"
>> 2. "we use dependency X, please configure it"
>> 3. "we use dependency X, please import the following from it"
>>
>> It'd be nice if I only had to say "I want to import from  
>> dependency X,
>> please make sure it's there and available." Actually this is a little
>> bit like zc.resourcelibrary can make resources appear on your page
>> headers when you write code that needs it.
>>
>> Of course this is sometimes not possible, as there's not enough
>> information available, or there are multiple separate ways to
>> configure it.
>
> In the end I guess this all is just more arguments for separating the
> functions and the views into separate eggs.

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.

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.  However, the presence of  
some ZCML in a non-Product library doesn't mean that its ZCML should  
be loaded, IMO.  Zope-3-the-application uses site.zcml to selectively  
load configurations, and I think that's about the right policy.  We  
could devise some way of spelling the equivalent of site.zcml as an  
entry point for eggs-that-are-applications, and as any "include  
package" directives in that zcml should "just work", there probably  
shouldn't be any additional machinery within zcml itself to cause  
other ZCML to be loaded from multiple packages via some omnibus  
search pattern.

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.  This is because even though it  
probably could (py2exe does something like this), it's more trouble  
than it's worth in because the import statements themselves don't  
contain enough information (version, location, is it an absolute  
requirement or a nice-to-have?) if you want to treat the dependencies  
as independently release-managed entities.  That said, if you just  
want to "freeze" some configuration up, it would become reasonable to  
treat some sandbox as a fully-configured set of things that should  
get packaged up as a glob and shipped off, but this is the opposite  
of what we want to do with eggs in the long term, I think.

- C