FHS, zopectl, #925, Re: [Zope-dev] 2.7 installation

[Chris McDonough]

On Wed, 2003-06-18 at 20:07, Adrian van den Dries wrote:

> Agreed; we can have a separate zopectl package that is dedicated to
> managing instances.

I'm hopeful that Luca agrees.

> > I'd advise against installing Zope library files into site-packages
> > unless you put them in a site-packages subdirectory (like
> > site-packages/zope270 or site-packages/zope271).  Otherwise there will
> > be no way to run multiple Zope versions on the same machine sanely
> > because different Zope versions have different libraries.
> 
> May I respectfully ask why there is so much concern with such
> complicated setups?  Surely a production environment (which is what
> any Zope distribution should aim for) will standardise on a software
> version?

It's often the case that you want to upgrade to a new Zope (or Python)
version on a machine and it's desirable that you be able to run both the
older version and the newer version on the same machine during the
cutover.

For this reason (and others), during production rollouts Zope
Corporation actually never uses the system-installed Python on a machine
nor does it use binary-packaged Zope distributions.  Instead, we install
a whole separate tree (typically inside of /home/zope) using CVS and
various source buildouts that looks like this:

bin/  (control scripts)
opt/   (software like Zope, Python, Apache, Zope products, etc.)
var/
  |
  |--zope/ (zope instance and data files)
  |
  |--apache/ (apache instance and data files)

We have make-driven software that creates us a tree via a single command
by checking out various version of Python, Zope, etc. from CVS and
compiling and installing them.  Different versions of Zope and Python,
etc. can be installed in opt and we use symlinks to manage versioning. 

We never install any Zope-related files to a particular Python's
site-package directory (even the Pythons we install ourselves) because
we like the flexibility of being able to use any Python version we like
without needing to copy Zope library files over between Python
site-package directories.  We just use the stock Zope software home blob
and munge the PYTHONPATH as necessary.

This works out pretty well in practice because we never have any
dependency on any system installed software besides C libraries, CVS,
make, and the shell.  This makes it easy to deploy Zope to many
(possibly divergent) systems without thinking too hard about system
incompatibilities and what's installed in a particular Python's
site-packages directory.

> If the concern is because *developers* want to run multiple Zope
> instances on multiple Zope versions with multiple Python versions,
> then I would suggest writing an *alternative* mechanism for developers
> to mangle their PYTHONPATHs and whatever.

It does benefit developers, but I don't think it's solely for the
benefit of developers.

It seems that most large systems install themselves this way; for
instance you can install multiple Apache versions on a single system
without regard for them stomping on one another.  Same for MySQL,
Postgres, etc.  It seems to be a fairly common pattern.  The fact that
we depend on Python doesn't seem to make much of a difference from the
perspective of someone installing Zope.  If Apache depended on Perl,
wouldn't necessarily expect my Apache to stop working because I deleted
some files from my Perl library directory.

> > That said, if you always manage upgrades via your package
> > distribution mechanism, and you only allowed one version of Zope to
> > be package-installed on the machine at once, perhaps putting the
> > files in site-packages wouldn't be such a big deal.
> 
> This is doubtless the most common scenario (or it should be).

It is when things go right, but when they go wrong, it's fairly limiting
to only be able to have a single version of Zope installed on your
system.

That said, it's really a packaging decision.  I'm currently most
concerned about making Zope to be easy to install from source.  If I can
add features to the source install to make it easy for binary packagers
to package Zope, I'll do so, but I won't limit the source installer to
installing to a single predeclared place.  The current Zope source
tarball install will continue to allow you to install multiple Zope
software homes on your system without regard to the Python you use to
invoke them.

The binary packaging scheme for a particular distribution is up to the
packager.  We can probably provide support in the setup.py file for
installing libraries to site-packages to help binary distributions do so
if they choose.  I don't think it's a particularly good idea, but I'm
not in charge of those distributions either, so my opinion shouldn't
count for much. ;-)

> > I'm afraid you're going to need to change a lot of things to support
> > Zope 2.7.  Please let me know if I can help.
> 
> Should we move this to debian-python?

Just tell me where to go and I'll go there. ;-)

> > Servicing the many goals of installation and configuration is very
> > difficult, but I'm pretty confident we can make your life a little
> > easier in the long term given that I understand your requirements.  It
> > will also make Zope that much more "debian-friendly" in the long run.
> 
> As long as we can distinguish those parts of this exercise that will
> apply to the Zope distribution from those that should be specific to
> Debian's package, this shouldn't be too hard.
> 

Yup.

Thanks for the input!

- C