[Zope-Coders] Making Zope2 more LFH compatible

[Chris McDonough]

On Thu, 2003-06-19 at 12:39, Christian Heimes wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> For now Zope2 isn't very LFH (linux filesystem hirachie) compatible.

I admit that I know nothing whatsoever about LFH, but that's probably
OK.  It's not really Zope itself that is incompatible with various
filesystem hierarchy standards, it's the result of a particular
installation.

That said, were you to say that "the result of installing Zope from the
current 2.6 binary release available on Zope.org is not LFS compatible",
I'd imagine this would be true.

But starting with 2.7, binary releases of Zope for UNIX platforms will
be be offered by Zope Corporation (they will however be offered for
Windows).  Instead, for UNIX platforms, only the source distribution
will be offered.

Given this, hopefully we can make it possible to use the source
installer to generate a filesystem layout that more or less complies
with any given hierarchy standard.  It is basically just a matter of
offering install-time file-location options.

 The
> last few changes from Chris gave me the idea to write this proposal how
> the the filesystem layout should be altered:
> 
> /usr/share/doc/zope - documentations
> 
> /usr/share/zope - shared files like skeletons under /usr/share/zope/skel
> 
> /usr/bin - zopemkinstance, zopemkzeo, zopectl ... (renamed utilities)

Thanks.  This suggests the need for a separate binprefix... I've added
this to the TODO.

> /usr/lib/zope - zope main files
> 
> /usr/lib/$PYTHON_VERSION/site-packages/Zope - softlink to or files from
> $ZOPE_HOME/lib/python/Zope/

There is really no reason for this, considering that, except for ZODB
and ZEO, we do not maintain most Zope packages/modules separately from
Zope itself.  The Zope packages for a given Zope release are related
directly to that release of Zope; older and/or newer versions of those
packages may or may not work with older or newer Zopes.

The things you put into site-packages are meant to be Python packages or
modules.  In this case, your 'Zope' directory cannot be a package
without many changes to the Zope source code because imports within Zope
would then need to be relative to the Zope package (e.g. instead of
'from Acquisition import aq_base', we'd need to change everything to
'from Zope.Acquisition import aq_base', etc.).  And if your Zope
directory is *not* a package (if it doesn't have an __init__.py in it),
there's no reason to put it into site-packages as it would still need to
be added to the PYTHONPATH, which brings us full circle to the place we
are right now.

Note that Zope3 does take the tact of rooting everything in a 'zope'
package namespace as you suggest above.  It's a bit too late for Zope2
to do that.

If people want to install the libraries that come with a particular Zope
release directly into site-packages (e.g. site-packages/Acquisition.so,
site-packages/AccessControl, etc), I see no reason to stop them,
however, and I think the source install should make that possible (but
not the default).

> /var/lib/zope/$INSTANCE_NAME/ - per instance data like zodb, products,
> imports ...

This is currently handled by mkzopeinstance.  ZODB file location can be
handled in the config file (zodb_db/filestorage/path).

> 
> /var/log/zope/$INSTANCE_NAME/ - zope logs

This can be specified in the Zope config file for each different Zope
log file.  (eventlog/path, access/path, trace/path).

> 
> /var/run/zope/$INSTANCE_NAME/Z2.pid - pid file

Ditto (pid-filename)

> 
> /var/lock/zope/$INSTANCE_NAME/Z2.lck - lock file

Ditto (lock-filename)
> 
> /etc/zope/$INSTANCE_NAME.conf - configuration files per instance

Config files can live anywhere.

You bring up some good points here.

To help binary distribution creators, mkzopeinstance probably needs to
make it easier to place instance files in separate directories and needs
to generate a zope.conf that reflects logfile/lockfile/pidfile placement
options that can be fed on the command line.

I have added this to the TODO, thanks.

> /etc/zope/__default__.conf - default configuration which could be
> overwritten by /etc/zope/$INSTANCE_NAME.conf

I'm afraid I don't understand what this is for, but it sounds like
something that would be used in a framework like Luca DeVita's debian
zopectl (e.g. it would not be a part of the Zope source install).

Thanks!

- C