On Thu, 2003-06-19 at 20:24, Adrian van den Dries wrote:
> 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?

This is somewhat of a style choice, but many people who come to Zope
don't know much about Python.  It is friendlier (imho) to inform them
they need to install a particular Python version (and where to get it)
to get Zope running after they invoke 'configure' without a Python
around rather than force them to read docs ahead of time to understand

But there is no need to use the shell wrapper.  It's purely a
convenience for this kind of user.  "Power users" can use
inst/configure.py directly if they so choose.  But I'm not going to
document it because if they're smart enough to know Python, they're
probably smart enough to know they can invoke it this way by reading the
shell script (as you were).

> 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?

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).

So, in any case, to get around this limitation, we have $FOUND1 -
$FOUND6 variables which keep the result of the search for acceptable
Python versions.  It's enforced by the use of these variables.  Were we
to want more, we'd just create a $FOUND7 and so on.

It probably could be made better, but I'd encourage you to just not look
at this if it bothers you and use the inst/configure.py script
directly.  The shell script isn't particularly pretty, good, or elegant,
but it serves its purpose.

> > 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.

I agree they should be allowed.

> 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.

I think I understand at least half of that.  Let me see if I can restate

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?

> > 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

I think it is possible to tweak many things now via make -e after
examination of the makefile.

> > - 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.

Well, if you ignore the shell scripts, I think we're ok, then!


- C

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to