Tim Hicks wrote:
>>>The reason for doing so is simple: Products is bound to go away. It
>>>gives a lot of people a lot of pain. With a lot of Zope 3 technology
>>>entering many Zope 2 projects, it would be good to get a clean slate
>>>early on: put new stuff on Product-less packages.
>>You can turn that around; for consistency of installation experience in
>>Zope 2.8, it's important that people don't get a new way of installing
>>products, confusing innocent individuals installing Zope software. For
>>the "cutting edge", Zope 2.9, that argument is slightly different.
> Coming at this with a zope 2 head on, it seems to me that it might be
> nice if I could carry on using the Products directory so that when I add
> new 'products', I don't have to mix them in with the core zope code in
> lib/python/.

What do you mean by "core zope code"? Zope lives in
SOFTWARE_HOME/lib/python, e.g. /usr/local/Zope-2.9.0/lib/python, your
own python packages live in INSTANCE_HOME/lib/python, e.g.

> But the separation of 'core' and 'extras' gives me a comfortable
> feeling.  Is it just me?  Am I just stuck in the past?

I think you're just confusing software home vs. instance home. We're not
making you put stuff into software home (although you can if you really
want to... you can even put stuff into site-packages or anywhere you
want as long as it's in PYTHONPATH).

Plus, just the fact that stuff *being* somewhere in the PYTHONPATH
doesn't mean it gets loaded. You have to add a ZCML slug to
INSTANCE_HOME/etc/package-includes first. So, you could install a
package globally and just make it available to certain instances by
placing a slug or not.

This is how package deployment works in Zope 3 and it's where we're
heading with Zope 2 as well.

for further info and some ranting as well as constructive suggestions.

Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to