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)
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)
Sounds very good to me. However, I guess the biggest bulk of the work will be to make the existing Products out there eggs, which is quite a tedious task.
A bit off topic: What about entry points for Zope 3 packages for their ZCML? Right now, when I easy_install a Zope 3 package, I still need to set up the ZCML by hand. I'm not sure that this is a sensible default.
Daniel
Daniel Nouri 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)
Sounds very good to me. However, I guess the biggest bulk of the work will be to make the existing Products out there eggs, which is quite a tedious task.
It is also left up to those who develop those products. This proposal doesn't propose to change any existing products. It just gives consumer frameworks the ability to deploy products just like any other Python egg.
A bit off topic: What about entry points for Zope 3 packages for their ZCML? Right now, when I easy_install a Zope 3 package, I still need to set up the ZCML by hand. I'm not sure that this is a sensible default.
Jim has plans to * create configuration actions from Python instead of XML * use entry points as the "include" mechanism
These plans were originally for Zope 3.4/2.11, not sure if it has been postponed by now. The PyCON 07 sprint may produce something. If Zope 3.4 gets it, Zope 2.11 will get it automatically. And yes, it will be very nice. All you then need is two entry points for a package and it's Zope2-enabled.
On Tue, 2007-23-01 at 23:58 +0100, 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)
A strong +1 here on the proposal.
- Rocky
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
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote:
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!
Well, we could probably add conflict-detection to the entry point handlers for Zope (ie so any two packages that try to register as the same project would cause an error). But regarding Products/CMFCore and lib/python/Products/CMFCore conflicting... that would be up to the standard pythonpath mechanism of the python interpreter (whichever is first on the path wins).
- Rocky
Rocky Burt wrote:
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote:
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!
Well, we could probably add conflict-detection to the entry point handlers for Zope (ie so any two packages that try to register as the same project would cause an error). But regarding Products/CMFCore and lib/python/Products/CMFCore conflicting... that would be up to the standard pythonpath mechanism of the python interpreter (whichever is first on the path wins).
Zope 2 itself manipulates Products.__path__ to add INSTANCE/Products (or any other directory specified in zope.conf) as a directory which can contain further products (the original Products package lives at ZOPE/lib/python/Products). pkg_resources uses the same mechanism for namespace packages (that's what the pkg_resources.declare_namespace('Products') call is all about); it appends to __path__.
Therefore, Zope will treat /path/to/the/CMFCore-egg/Products as another directory that contains a product (in this case just one, CMFCore). Thus the standard product override rules apply when the same product is installed in multiple directories.
I updated the proposal text with this information.
Philipp von Weitershausen wrote:
Rocky Burt wrote:
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote:
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!
Well, we could probably add conflict-detection to the entry point handlers for Zope (ie so any two packages that try to register as the same project would cause an error). But regarding Products/CMFCore and lib/python/Products/CMFCore conflicting... that would be up to the standard pythonpath mechanism of the python interpreter (whichever is first on the path wins).
Zope 2 itself manipulates Products.__path__ to add INSTANCE/Products (or any other directory specified in zope.conf) as a directory which can contain further products (the original Products package lives at ZOPE/lib/python/Products). pkg_resources uses the same mechanism for namespace packages (that's what the pkg_resources.declare_namespace('Products') call is all about); it appends to __path__.
Therefore, Zope will treat /path/to/the/CMFCore-egg/Products as another directory that contains a product (in this case just one, CMFCore). Thus the standard product override rules apply when the same product is installed in multiple directories.
I updated the proposal text with this information.
I imagine it would be pretty trivial to write something that would generate a setup.py from an svn:externals property so you could create a "Products" distribution in one fell swoop, especially since the entry point section of the setup.py can handle config parser output.
-w
whit wrote:
Philipp von Weitershausen wrote:
Rocky Burt wrote:
On Thu, 2007-25-01 at 05:07 -0800, Martin Aspeli wrote:
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!
Well, we could probably add conflict-detection to the entry point handlers for Zope (ie so any two packages that try to register as the same project would cause an error). But regarding Products/CMFCore and lib/python/Products/CMFCore conflicting... that would be up to the standard pythonpath mechanism of the python interpreter (whichever is first on the path wins).
Zope 2 itself manipulates Products.__path__ to add INSTANCE/Products (or any other directory specified in zope.conf) as a directory which can contain further products (the original Products package lives at ZOPE/lib/python/Products). pkg_resources uses the same mechanism for namespace packages (that's what the pkg_resources.declare_namespace('Products') call is all about); it appends to __path__.
Therefore, Zope will treat /path/to/the/CMFCore-egg/Products as another directory that contains a product (in this case just one, CMFCore). Thus the standard product override rules apply when the same product is installed in multiple directories.
I updated the proposal text with this information.
I imagine it would be pretty trivial to write something that would generate a setup.py from an svn:externals property so you could create a "Products" distribution in one fell swoop, especially since the entry point section of the setup.py can handle config parser output.
As an example, I'd like to point to my 'install-plone.py' script again, which does it the other way around. There, the Products/ directory in SVN pulls in the Products via svn:externals, and the only thing that remains is 'Products/__init__.py' with the namespace declaration. This is of course less than ideal for controlling versions (although the svn:externals might just as well point to a tagged bundle), but maybe good enough for the 'legacy' (can we call Products that?) code that we have.
BTW, compare the difference in size between that script[1] and ploneout[2]. I should mention that it does less than ploneout (it doesn't download Zope 2, but that'd be trivial to add) and it could be argued that it's less flexible for some definition of flexible. (Sorry for being OT here.)
[1] http://danielnouri.org/svn/scratch/Plone/trunk/install-plone.py [2] http://svn.plone.org/svn/plone/ploneout/trunk/
Daniel Nouri-3 wrote:
BTW, compare the difference in size between that script[1] and ploneout[2]. I should mention that it does less than ploneout (it doesn't download Zope 2, but that'd be trivial to add) and it could be argued that it's less flexible for some definition of flexible. (Sorry for being OT here.)
[1] http://danielnouri.org/svn/scratch/Plone/trunk/install-plone.py [2] http://svn.plone.org/svn/plone/ploneout/trunk/
Well, I'd say that ploneout is only this big: http://svn.plone.org/svn/plone/ploneout/trunk/buildout.cfg
There are svn:externals to the products and eggs.
There are also generic recipes for installing zope 2 and setting up a zope 2 instance and downloading tarballs for products. These are basically this big:
http://svn.plone.org/svn/plone/ploneout/trunk/src/z2c.recipe.zope2install/sr... http://svn.plone.org/svn/plone/ploneout/trunk/src/z2c.recipe.zope2instance/s... http://svn.plone.org/svn/plone/ploneout/trunk/src/z2c.recipe.distros/src/z2c...
Still a bit longer than your script, but not quite so scary. :) The zope 2 install recipe is the only one that's not mostly trivial (if you consider shell and file operations trivial). That recipe tries to give you a lot of flexibility to control what the instance (and thus the deployed environment).
That said, I quite like your script as an example of using workingenv from python to set this stuff up.
Martin
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.
-
Daniel Nouri -
Martin Aspeli -
Philipp von Weitershausen -
Rocky Burt -
whit