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%22Products%22%29-tf3077929.html#a8612115
Sent from the Zope - Dev mailing list archive at Nabble.com.

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

Reply via email to