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

On 10/22/07, Martijn Faassen <[EMAIL PROTECTED]> 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

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to