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

[Adrian van den Dries]

On June 19, Chris McDonough wrote:
> On Wed, 2003-06-18 at 23:13, Adrian van den Dries wrote:
> >   python2.1 configure.py --prefix=/opt/zope271-python21
> 
> (FWIW, configure is a shell script.)

Yes, I knew that.  I used the .py extension for all the scripts to be
consistent, according to my earlier point to this end.

It too is just a shell wrapper to find the correct python and palm off
the remaining options to inst/configure.py.  Why not avoid that
altogether and let the user supply the correct python?

Ie, instead of::

  ./configure --with-python=/usr/bin/python3.2 --other --options

you call::

  /usr/bin/python3.2 configure.py --other --options

Which it pretty much does, anyway.

I also see things like this:

  # Up to six acceptable python versions are allowed.

Why six?  Where is it enforced?

> Are you implying that the stuff that currently goes into
> software_home/lib/python would be installed to the site-package
> directory of the Python that was used to invoke the installer?  If so,
> the subsequent invocations above of:

No, I'm saying that the systems should be allowed (or even encouraged)
to do this.  We already have sys.path and namespaces.  In a 1:1
python:zope environment, this should be enough to identify the Zope
packages.  Hence installing into python's module path.  For
multiple-version environments, you need --home (see below).

>    cd Zope-2.7.1
>    python2.1 configure.py --prefix=/opt/zope271-python21
>    make; make install
> 
>    cd ../Zope-2.7.2
>    python2.1 configure.py --prefix=/opt/zope272-python21
>    make; make install
> 
> ... would cause the Zope 2.7.1 libraries to be stomped by the Zope 2.7.2
> libraries.

No, because --prefix just told configure.py to install *everything* in
that location.  If you want to alias this option to --home, that would
probably make this clearer, but I don't think it's different in
function.

> If you mean that the libraries are installed into
> /opt/zope27X-python21/lib/python, there's no problem and nothing about
> the installer needs to be changed.

Aye.

> So, in any case, given that the ZC source tarball installer will not
> attempt to manage multiple instances (we'll leave that to Luca)

Aye.

> here are the requirements I've gathered so far:
> 
> - Add a --doc flag to configure
> - Add a --skel flag to configure (is this a common pattern?)

I think so.  But consider using the Make variables suggested
earlier, so that distributions may customise the make step:

./configure --options --supplied --by --zope
make SITE=local SPECIFIC=options

> - Make it possible to install Zope libraries into the site-packages
> directory of the Python that invokes Zope's setup.py instead of into
> software_home/lib/python.

As long as each of the top-level Zope directories in the --home (bin,
doc, lib, skel) can be individually tweaked, either in the
configure.py or the makefile, I think we win both ways.

> Am I missing anything?

Apart from my personal desire to see the shell scripts deprecated,
nope.  ;-) I think that's covered everything that concerns Zope
itself, and the rest gets palmed off to zopectl and packagers.

a.

-- 
 Adrian van den Dries                           avdd@flow.com.au
 Development team                               www.dev.flow.com.au
 FLOW Communications Pty. Ltd.                  www.flow.com.au