Hash: SHA1

Wichert Akkerman wrote:
> Martin Aspeli wrote:
>> Fred Drake wrote:
>>> On 10/17/07, Wichert Akkerman <[EMAIL PROTECTED]> wrote:
>>>> A common issue we are seeing is that we have eggs depending on each
>>>> other, but they still need to load the zcml from those dependencies
>>>> somehow. As a temporary solution to play with the concept I added
>>>> something simple to the plone.recipe.zope2instance buildout recipe.
>>> What's the problem you're seeing?  I'm not sure what you're trying
>>> to
>>> solve.  ZCML includes work just fine in the egg world.
>>> As long as you're referring to packaged ZCML using
>>> package="package.name" in your <include> and <includeOverrides>
>>> directives, all is good.
>> The main win, IMHO, is to avoid the requirement for people to install 
>> slugs for third party products. Slugs suck - they are confusing to 
>> explain and people forget them all the time. Buildout makes it a bit 
>> easier, but it's still not a terribly good solution.
>> For example, say you want to install oi.plum. You need to add the
>> line 
>> 'oi.plum' twice - once under 'eggs' and once under 'zcml' in your 
>> buildout.cfg. Forget the latter, and the package doesn't work
>> properly 
>> (or at all).
> I see a different win. At the moment we are declaring dependencies in
> two places: in the egg information and in the zcml files. For every
> package I need I need to make sure its zcml is loaded, which means I
> need to have a meta.zcml, configure.zcml and overrides.zcml which load
> the meta, configure and overrides from all packages I depend on. I also
> need to inspect every package I depend on to check if they have a meta,
> configure or overrides.zcml, which in my humble opinion should be just
> an implementation detail that I, as someone who is just using the zope
> stack/framework, should not need to know about. Multiply that with the
> number of dependencies you see in zope.* and you see this becomes very
> unwieldy.
> So I turned things around: if I state in my egg information that I
> require another package that means I need to have that package
> available and functional. Which suggests that its zcml has to be loaded
> before mine. And that is exactly what I am doing: adding an entry point
> that allows a package to say "in order to function I need to have these
> zcml files loaded".

I may not *want* the other package's ZCML to be loaded:  some of its
policies may not be appropriate for my application.  I think that the
"library" vs. "pluggable application" distinction is valid here:  maybe
you want to define an entry point in the egg which a given pluggable app
would use at startup time to configure all the plugins which exposed
that entry point.  Five fakes such an entry point now by implicitly
loading meta.zcml, then configure.zcml, then overrides.zcml for all
packages it recognizes as products:  are you proposing to replace Five's
DWIM with a new, explicit version?

- --
Tres Seaver          +1 540-429-0999          [EMAIL PROTECTED]
Palladion Software   "Excellence by Design"    http://palladion.com
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

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

Reply via email to