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 - Products in lib/python would be picked up by entry point rather than scanning Products/ - 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 - This would supersede the five:registerProduct directive we have now If so, this sounds great, so +1 :) I do wonder what would happen if you had both lib/python/Products/CMFCore and Products/CMFCore, though. Would there be an explicit preference or would Zope fail to start up with a conflict? I think I'd prefer the latter, in fact, so that people don't end up modifying/upgrading the wrong code by accident! Martin -- View this message in context: http://www.nabble.com/RFC%3A-Eggifying-Zope%27s-extension-mechanism-%28%22Pr... Sent from the Zope - Dev mailing list archive at Nabble.com.