[pony-build] Thoughts on the python version checking code

[C. Titus Brown]

Hey Jack,

looking at your function 'test_python_version', here:

   http://github.com/ctb/pony-build/blob/master/client/pony_client.py#L885

and used here:

   http://github.com/ctb/pony-build/blob/master/client/build-quixote

I wanted to suggest changing it around a bit.

To back up:

--

We're facing at least two problems with python versions.  The first (and
more annoying one) is a difference between Windows and Linux.

On Linux, different versions of Python are installed under duplicate names,
e.g. 'python2.5' and 'python' can point to the same Python (2.5), while
'python2.6' is invoked only for Python 2.6 [0].  

On Windows, different versions of Python are installed in different
places, so you need to explicitly call them if you want to choose a
specific version.

Why is this a problem?

pony-build client scripts want to know, control, and report the version of
Python that they're using to run builds.  Because I'm primarily a UNIX
guy, I did this by

 (i) making the first argument to build scripts after the flags describe the
     Python binary to run; e.g. see

        http://github.com/ctb/pony-build/blob/master/client/build-twill

     lines 13-15;

 (ii) putting the argument into the tags that are reported to the server
     and used to distinguish between different builds, e.g.

        http://lyorn.idyll.org/ctb/pb-dev/p/distutils2/

     where you see 'python2.6', 'python2.5', etc.

Unfortunately this means that on Windows you don't get this information,
though, because you just run 'python' (which can also happen on Linux,
as you can see in the distutils2/ page).

So I'd really like python-using scripts to go figure out what version of
Python they're running.  Back to Jack -- I think that it would be easy to 
modify the function you wrote to actually call the Python binary and
retrieve the info from it using 'sys.version_info'.  This information
could then *also* be stuffed into 'tags', solving the cross-platform
problem, too.

** Jack, what do you think?

Right now what your function does is trust that if it *can* call
'python2.5' then it is the right version.  I think this is a bit more
effective: it requires that the Python binary actually *lie* :).

--

Separately, there's the question of *how* to specify the version of Python to
run via the command line.  I think the above idea makes it easier to identify
the wrong version of Python; so how do we specify the binary to run?

I don't like the idea of hard-coding it in to the optparse command line
options, but if you look hard at pony_client.py you'll see where I've
made a start on providing a simple macro-style language for replacement;
search for PB: in the file.

(Rose, don't say anything -- I know it's ugly and limited.  Thanks ;)

We could easily use this mechanism to supply "global" macros, e.g.

   python_exe

that anyway could use in their build scripts for replacement, e.g.

   % build-script -M python_exe=python2.5

or

   c:\> python.exe -M python_exe=c:\python25\python.exe

and then python scripts would stuff the 'python_exe' value into the tags, and
we could write generic recipes using that macro [1].

** Jack, what do you think?

--

cheers,
--titus

[0] Incidentally, this is one way on UNIX that you can pin your scripts
to a specific version of Python: put

	#! /usr/bin/env python2.5

at the top to make it run under the first python2.5 it finds in the path.

[1] As you can sort of see me trying to do at the bottom of pony_client.py.
-- 
C. Titus Brown, ctb at msu.edu