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 Infrae × http://infrae.com