> #!/usr/bin/python2.5 works for me.
Works on the OLPC and on some Linuxes. Not everybody puts Python
in /usr/bin, unfortunately. That's a local system dependency, rather
than a global constant -- but there it is in your portable Python
program. :-(
I've seen others do "#!env python2.5" which at least has the benefit
of not hardwiring the execution path. It also requires a second small
executable, which is widely available in Unix/Linux systems as part of
the GNU Coreutils (and busybox). But are you sure that python2.5 is the
name of Python 2.5 everywhere? Not "python-2.5", not "python.2.5",
not "python_2.5", not "Python 2.5"?
I think it would be better to have a system library that would
re-execute a different interpreter (in a system-dependent way) if
the one that started this Python program wasn't an acceptable version.
Thus you could use #!python, then something like:
import pyversion from pyversion
version.enforce(2.5)
This could be implemented in an arbitrarily complex way, such as:
* return immediately if the right version is running.
* Complain bitterly if this is a second call and demands a different version
than the first call (e.g. main program wants 2.4, library wants 2.5).
* Complain bitterly if the main program has done something irrevocable
before this call, and thus exec() won't do the right thing.
* exec() the right version if it's installed elsewhere in the system.
* Unpack the right version from a tar file into a cache directory, exec it.
* Try "apt-get install python-$version" and then exec it.
* Try doing a home-directory apt-get if you don't have system install
permission (a la "xo-get").
* Check the mesh to see if any nearby laptop has it.
* ...etc...
John
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
