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