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
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
