[Zope-dev] 2.7 installation

[Chris McDonough]

On Wed, 2003-06-18 at 06:18, Adrian van den Dries wrote:
>   1. one --prefix is too limiting with this tree. You can't install
>      into an existing hierarchy like /usr, because of the zope-specific
>      directories "import", "skel" and "utilities".

Yes.  Good point.  I'd like to see us change the directory structure
around so that installation into an existing prefix would be possible. 
This would imply getting rid of "import", "skel", and "utilities" and
might mean (as per your suggestion) allowing more specific prefix
targets for docs, lib, exec, etc.

This is a bit of work, but would be possible.  The setup.py script would
need to be pretty smart.

However, if we end up keeping it the way it currently is, the --prefix
option should really be named --home so as to prevent any
misunderstanding.

>   2. $INSTANCE/bin/* are just shell wrappers for their respective
>      scripts in $PREFIX/bin, serving only to point to the correct
>      configuration and software paths, also requiring you to supply a
>      full path to the script.  This should instead be a global control
>      script that takes an instance name as an argument:

>      # zopectl -i default start

Actually the scripts in $INSTANCE/bin aren't shell wrappers for things
in $PREFIX/bin, they're shell wrappers for thing in
$PREFIX/lib/python/Zope/Startup.  But yes, they are shell wrappers.

If you made a global control script that worked as per your example, how
would you identify where the 'default' instance is?

FWIW, I'd be very opposed to any sort of limitations on where instance
homes could be placed to service this global control script's need to
find instances.

If you have only one Zope instance on your machine, you can link the
zopectl script to /usr/bin/zopectl and get the convenience of typing
'zopectl' to do what you mention instead of '/path/to/zopectl'.

If you have more than one Zope instance on your machine, I think they
should be controlled by separate scripts instead of requring a framework
to manage multiple instances on the same machine through some sort of
path identification or config file listing all instances on the
machine.  See my comment in
http://dev.zope.org/Wikis/DevSite/Proposals/InstallationAndConfiguration
dated Aug 22, 2002 8:09 pm for more background.

>   3. This installs all of Zope, ZODB, ZEO and zdaemon.  I am
>      uncomfortable with this blurring of function between applications
>      (runzeo.py) and libraries (ZODB)

OK.

> 
> For Zope
> ========
> 
> The make install step::
> 
>   EXECPREFIX=$PREFIX
>   LIBPREFIX=$PREFIX
>   SKELPREFIX=$PREFIX
>   DOCPREFIX=$PREFIX
> 
>   BIN=$EXECPREFIX/bin
>   LIB=$LIBPREFIX/lib # python, etc.
>   DOC=$DOCPREFIX/doc
>   SKEL=$SKELPREFIX/skel
> 
> With ``PREFIX=/zope``, you get::
> 
>   /zope/bin/
>             zopectl.py
>             runzope.py
>             utils.py etc.
>   
>   /zope/doc/
>             import/
>                    Examples.zexp
>             README.txt etc.
> 
>   /zope/lib/
>            python, etc
> 
>   /zope/skel/
>              Extensions/
>              Products/
>              etc/
>              import/
>              log/
>              var/

This sounds good.  I'm not so sure about $SKELPREFIX.  Maybe we could
just move the skel directory into the lib directory and consider it part
of Zope's libraries.

Also, currently the scripts in $PREFIX/bin rely on being in a directory
which peers with the lib directory.  This would need to change were we
to be able to specify an execprefix.  Additionally, a particular
execprefix would need to depend on the existence of a particular
libprefix (the scripts in bin rely on being able to import stuff from
libraries in the lib directory).  This is why they're currently not
broken apart.

> Then the administrator (or initial installation) runs::
> 
>   # mkzopeinstance /var/lib/zope/default/var -l /var/log/zope/default
> 
> which copies ``$SKEL/*`` to ``/var/lib/zope/default``.

What does -l do?

> 
> To start, stop, restart zope::
> 
>   # zopectl default (start|stop|status|restart|etc)
> 
> Other Z* packages
> =================
> 
> Note that the above procedure installs only Zope.  It requires ZODB (a
> standalone package) to be installed.


It is not desirable to make people configure and install ZODB separately
if they install from a tarball source distro.

With package-managed distributions (especially apt which has very nice
automated dependency management), this isn't such a big deal, but we
want to make it easy to install a running Zope from source using with
maximum complexity of './configure; make; make install'.

That said, I agree in sentiment.  If you want to change the setup.py
script for Zope to "do the right thing" so it invokes ZODB's setup.py
and the outcome is the same, I'd have no problem with that.  Ditto for
ZEO.

> Debian packages ZEO and the ZODB similarly, and ZEO and Zope depend on
> the ZODB.

In the past, my offers to provide upstream support for Debian packaging
hasn't been met with much enthusiasm.  If I can make it easier for
people to package Zope for Debian, I'd love to, but I'd need to have
some buyin and support from the current Debian packagers.  Otherwise, it
ends up being a waste of time on both of our parts as it won't be what's
best for either of us.

Debian's packaging and installation strategy for Zope has always been
very customized and divergent from the Zope source distribution's
packaging and installation strategy.  At very worst, it could stay this
way.


- C