[Zope-dev] Re: RFC: Eggifying Zope's extension mechanism ("Products")

[Daniel Nouri]

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