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