Tim Hicks wrote:
>>>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.
>>/var/zope/foobar.com/lib/python.
> 
> Ah, ok, I think I am/was confused between INSTANCE_HOME and
> SOFTWARE_HOME.  Part of the confusion stems from me looking at the
> directories that I have in my Zope 2.8.1 instance and seeing the following:
> 
> [EMAIL PROTECTED] ~/zope/instance1 : ls -l
> total 16
> drwxr-xr-x   2 tim2p  tim2p   512 Sep 20 01:28 Extensions
> drwxr-xr-x  47 tim2p  tim2p  1536 Jan 15 23:20 Products
> -rw-r--r--   1 tim2p  tim2p   410 Sep 19 21:44 README.txt
> drwxr-xr-x   2 tim2p  tim2p   512 Sep 19 21:44 bin
> drwxr-xr-x   2 tim2p  tim2p   512 Sep 19 21:44 etc
> drwxr-xr-x   2 tim2p  tim2p   512 Jan 11 10:48 import
> drwxr-xr-x   2 tim2p  tim2p   512 Dec 19 02:49 log
> drwxr-xr-x   3 tim2p  tim2p   512 Jan 16 12:14 var
> 
> No lib/ (and therefore, no lib/python/) directory.  Once I saw you guys
> talking about lib/python/, I assumed you must have meant the one in
> SOFTWARE_HOME.
> 
> Presumably instances are going to grow a lib/python/ directory too.

Yes. In fact, if one exists, it's automatically put on your PYTHONPATH
for that instance. I think we should make Zope 2.8+ instance skeleta
grow a lib/python directory. This can hardly be considered a feature, so
we should be able to sneak it into the next bugfix releases of 2.8 and 2.9.

> How
> would that be different to just having those packages that appear in the
> current (INSTANCE_HOME) Products/ directory just be directly importable
> without the "Products." part in the import statement?  I suppose
> lib/python/ is more normal in the python world...

Yeah, lib/python is a bit more normal (though it adds that extra path
element which feels like clutter). Plus, your suggestion with a
two-faced Products (once a PYTHONPATH container, once a top-level
package) would make everything a bit ambiguous.

Also, Products sort of acts as a namespace package. When we move to
top-level packages, people might want to choose different namespace
packages (e.g. Plone would hopefully choose 'plone' instead of
'CMFPlone' and the CMF might regroup everything under 'cmf', e.g.
'cmf.core', 'cmf.default', etc.)

Philipp
_______________________________________________
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

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

Reply via email to