[Zope-Coders] Re: Making Zope2 more LFH compatible

[Chris McDonough]

On Fri, 2003-06-20 at 09:38, Christian Heimes wrote:
> | 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).
> 
> Do you have any ideas how to do this? I symlink can produce failurs and
> a copy of the files is not very beautiful.

We're currently trying to hash this out in the thread entitled "2.7
installation".  The prevailing notion is that this will be spelled by a
flag to the configure script.

> |>/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).
> 
> Yes, but there is no var for the $INSTANCE_NAME, only for the path to
> the $INSTANCE. With a %define INSTANCE_NAME myinstance people could use
> this var for e.g. /var/run/zope/$INSTANCE_NAME/Z2.pid.

Currently, the instance is only be identifiable by its place on the
filesystem.  The config file is what controls all other bits.  If we
keep things like they are, and we want to allow people to specify paths
for the various logfiles, pidfile, Data.fs file, etc, they will need to
specify these paths explicitly via mkzopeinstance flags instead of using
a by-name convention.

But ZConfig also allows you to declare simple variables in the config
file and use the variable via string replacement, so the default
generated config file could use embed an instance name this way.

That said, the act of naming an instance is bordering on "frameworkness"
that bothers me a little.   If it made distribution packagers' lives
collectively easier, however, it might be worth it.

I'll obviously need to think about this a little more.

> | 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.
> 
> There should be command line arguments for
> * pidfile
> * logfile
> * lockfile
> * effective user and effective group under that zope is running, so
> directories and files (log, pid, import ...) could be chowned to this
> user.group
> * conf
> * instance name and a way an instance name macro could be used in the
> command line
> 
> example
> $ mkzopeinstance --instance-name main --uid zope --gid zope --pid-file
> /var/run/zope/%INSTANCE_NAME%/Z2.pid --conf-file
> /etc/zope/%INSTANCE_NAME%.conf --lock-file
> /var/lock/zope/%INSTANCE_NAME%/Z2.lck /var/lib/zope/%INSTANCE_NAME%
> 
> AFAIK %INSTANCE_NAME% is not expanded by a unix shell so it could be
> recognized by the script.

I'm a bit uncomfortable with this particular example because it
conflates the responsibilies of mkzopeinstance to both specify an
instance name and do string interpolation of option values based on that
instance name.  That seems to be too much magic in the general case.

In order to keep it simple, I'd rather that people were made to explicit
about file-location paths passed to mkzopeinstance.

However, if someone were interested enough, they could write a front-end
management system that invoked mkzopeinstance with the proper file paths
that revolved around a particular filesystem layout based on an
"instance name" .

> |>/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).
> 
> My idea was to have a config file with no macro expansion which could be
> included in other config files.

I see... I think this also may be outside the scope of simple
installation, but is something a frontend system could handle.

Thanks!

- C