On June 19, Chris McDonough wrote:
On Thu, 2003-06-19 at 20:24, Adrian van den Dries wrote:
Why not avoid that altogether and let the user supply the correct python?
This is somewhat of a style choice
OK, ZC's call. ;-)
Well, as we all know, shell scripting kinda blows. There is no way that I know of to portably use an array in shell, and I wanted to eventually make it possible to use something other than bash to run the configure script (bash has arrays, but I'm not sure if bourne shell does).
You may be interested in Kenneth Almquist's ash (aka dash in Debian): Description: The Debian Almquist Shell "dash" is a POSIX compliant shell that is much smaller than "bash". We take advantage of that by making it the shell on the installation root floppy, where space is at a premium. . It can be usefully installed as /bin/sh (because it executes scripts somewhat faster than "bash"), or as the default shell either of root or of a second user with a userid of 0 (because it depends on fewer libraries, and is therefore less likely to be affected by an upgrade problem or a disk failure). It is also useful for checking that a script uses only POSIX syntax.
You're suggesting that "--prefix" be changed to "--home". ... You're suggesting that specifying a "--home" implies that libraries will be installed to $home/lib/python.
This is where I get a little confused. How does a user signify that Zope libraries should get installed into the Python site-package directory? What happens if "--home" is left unspecified? Is the "--prefix" option still around? If so, what does it do? Can you give an example of a configure command that would imply that Zope libraries get installed to site-packages?
Erm, yes. I originally wanted --home and --prefix aliased, but I've changed my mind. It should mirror the behaviour of the same options to the distutils' install target. With the distutils, ``--home`` is version-agnostic (installs package ``foo`` into ``$HOME/lib/python/foo/``) and ``--prefix`` is version-aware (installs into ``$PREFIX/lib/pythonX.Y/site-packages``). ``inst/Makefile.in`` could probably be updated to do a --prefix install if $(PREFIX) is defined, else it defaults to a --home install. (Mockups) # the next commands are all equivalent # and produce the install target # ``python setup.py --home=/usr/local/zope`` python inst/configure.py --home=/usr/local/zope ./configure --home=/usr/local/zope ./configure # the next command produces the install target # ``python setup.py --prefix=/usr/local`` # which installs packages to /usr/local/lib/python2.2/site-packages python inst/configure.py --prefix=/usr/local
I think it is possible to tweak many things now via make -e after examination of the makefile.
OK, that is what the Deb should do.
Well, if you ignore the shell scripts, I think we're ok, then!
Peaches! ... (Couple of hours later). OK, attached is a patch to inst/Makefile.in and inst/configure.py that distinguishes --home and --prefix parameters and passes them onto the distutils. But for some reason, there is still no difference between --prefix and --home, even though it's passing those options to the distutils. I suspect it might have something to do with this exerpt from setup.py:: # We create a custom "install scheme" that works the same way on all # platforms. We do this in order to prevent distutils from trying to # guess where to put our files on a per-platform basis. ZOPE_INSTALL_SCHEME = { 'purelib': '$base/lib/python', 'platlib': '$base/lib/python', 'headers': '$base/lib/python', 'scripts': '$base/bin', 'data' : '$base/lib/python', } That looks a little evil to me. a. -- Adrian van den Dries avdd@flow.com.au Development team www.dev.flow.com.au FLOW Communications Pty. Ltd. www.flow.com.au