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