[Zope-dev] Re: RFC: Eggifying Zope's extension mechanism ("Products")

[Philipp von Weitershausen]

Martin Aspeli wrote:
> Philipp von Weitershausen wrote:
>> For their upcoming versions, Zope 2 consuming platforms such as Plone
>> are creating standard Zope3-style Python packages while still having
>> Zope 2 products around.  This proposal aims at unifying the deployment
>> of products and Python packages into a Zope 2 instance alike by using
>> Python eggs and their entry point system.
>>
>> See 
>> http://wiki.zope.org/zope2/EggifyingZopesExtensionMechanismQuotProductsQuot 
>> for the full proposal. Comments are appreciated. I plan on implementing 
>> it at the Camp5 BBQ sprint (http://www.openplans.org/projects/bbq-sprint)
>>
> 
> So, to be clear:
> 
>  - You would have lib/python/Products/CMFCore as an alternative to
> Products/CMFCore

Sorta. Just placing a package into lib/python doesn't register the entry 
point. Products.CMFCore would have to be installed as an egg, e.g. using 
a global easy_install, workingenv in an instance or zc.buildout. In the 
latter case, the packages don't end up in 'lib/python' of the instance 
but in 'eggs' of the buildout. An example with workingenv would look 
like this:

   $ mkzopeinstance inst
   $ python workingenv.py --home inst
   $ cd inst
   $ . bin/activate
   (inst)$ easy_install Products.CMFCore
   ...

>  - Products in lib/python would be picked up by entry point rather than
> scanning Products/

Yes.

>  - The entry points would work with non-products as well, e.g. if
> lib/python/plone/foobar had the entry point, it could be a project

If by project you mean product, then yes.

>  - This would supersede the five:registerProduct directive we have now

Yes. Well, not supersede, but be an alternative.

> If so, this sounds great, so +1 :)

Great.

-- 
http://worldcookery.com -- Professional Zope documentation and training
Next Zope 3 training at Camp5: http://trizpug.org/boot-camp/camp5