[Zope-dev] Re: [z3-five] RFC: The future of Products.Five(green eggs and zope)

[Daniel Nouri]

Chris McDonough wrote:
> 
> On Oct 31, 2006, at 11:30 AM, Daniel Nouri wrote:
> 
>> Tres Seaver wrote:
>>> Daniel Nouri wrote:
>>>>> whit wrote:
>>>>> <snap>
>>>>>> We still have to handle the Products issue for add ons(mcdonc, donde
>>>>>> estamos con Basketos?). But if Basket is added to 2.11, this might
>>>>>> not
>>>>>> be such a big deal.
>>>>>> From what I know, Basket has been abandoned and there's even no good
>>>>> reason for using it.  Inside a workingenv you can just go and install
>>>>> egged Products without problems.
>>>
>>> Basket gives Zope the framework to tickle the 'initialize' entry point
>>> in eggs, which is *not* unnecessary AFAIK.
>>
>> 'intialize' will be called for eggs that use the Products namespace
>> package.  If the Product lives outside of Products, it must use the
>> 'five:registerPackage' directive so that its 'initialize' is called.
> 
> I know nothing of five:registerPackage, but Basket's model doesn't care
> whether or not a package is in the Products namespace.  It has two
> modes: DWIM mode, which calls "initialize" for all packages in eggs
> which have a "zope2.initialize" entry point, and a non-DWIM mode under
> which you must spell out the packages that should be initialized in a
> separate INI file (this is akin to using ZCML to spell out each of
> them).  Note that in the model that basket uses, an egg might contain
> more than one Product as well.  The egg contains a 'zope2.initialize'
> entry point for each product which the egg contains.  I've pasted the
> Basket readme to the end of this email, which explains all of this.

I've tried out Basket and failed.  I think it doesn't work for Zope 2.9
and newer.  However, having installed other Python packages through
easy_install before, I also found it a bit unintuitive to use (in theory).

I think Basket is overdoing it.  Zope 2 doesn't need such a specialized
egg story.  If we can install eggs the normal way (easy_install) and
they work and we can use known techniques (zcml slugs) to include them
in an instance, at least *I* am happy.

Entry points are definitely great and I do hope that they'll replace
zcml slugs soon.  That'll have to work for Zope 2 packages too (so
five:registerPackage becomes unnecessary) and I think there we can learn
from Basket.

>>
>> One thing to note is that if you install such an egg that has a Products
>> namespace system-wide, it will be 'initialize'd in every Zope instance.
>>  So it's advisable to 1) not use the Products namespace package and rely
>> on 'five:registerPackage' if you need 'initialize' and 2) use workingenv
>> or zc.buildout to install the eggs.
> 
> I think the reason that Phillip put entry points in the egg spec is just
> for this sort of thing.  I'm not sure if they're being used now for Zope
> 2 eggs (or if there even is such a thing), but imo they probably should be.

AFAIK, for both Zope 2 and Zope 3 you have to put a zcml slug into
package-includes.  (For Zope 2 only if you live outside Products though.)

Check out Whit's blog entry [1] if you haven't done so.  He explains how
to set up a workingenv inside a Zope 2 instance.

I recently played with a script that installs Plone by setting up a Zope
instance combined with a workingenv, and pulling all necessary Products
and packages in as eggs [2].


[1] http://bfhammer.blogspot.com/2006/09/bootstrapenvironment.html
[2] http://lists.plone.org/pipermail/framework-team/2006-October/000784.html