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
/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
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
> 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.
> So, in any case, given that the ZC source tarball installer will not
> attempt to manage multiple instances (we'll leave that to Luca)
> 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
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.
Adrian van den Dries [EMAIL PROTECTED]
Development team www.dev.flow.com.au
FLOW Communications Pty. Ltd. www.flow.com.au
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -