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 [EMAIL PROTECTED] Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )