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
and Products/CMFCore, though. Would there be an explicit preference
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
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.
------ d. whit morriss ------
- senior engineer, opencore -
- http://www.openplans.org -
- m: 415-710-8975 -
"If you don't know where you are,
you don't know anything at all"
Dr. Edgar Spencer, Ph.D., 1995
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -