Thanks for the series of explanations. It sounds like there is no
perfect solution, but that #!/usr/bin/env python will be most likely
to work on most systems.
For my own system, I might add a PYTHONPATH line to my .profile that
references both 'system' and 'macpython' site-packages. This might
help in other circumstances.
Michael
On Jul 29, 2008, at 8:37 PM, Glynn Clements wrote:
William Kyngesburye wrote:
Given that the two versions are almost identical (2.5.1 vs 2.5.2), I
suggest setting PYTHONPATH to contain both modules' site-packages
directories, and nothing else.
Or make sure the correct python is running.
They are similar versions, but compiled differently - one (2.5.1)
for OSX Leopard, the other (2.5.2) for Tiger and also-works-on-
Leopard. The Mac Python list would have a better idea if this a
workable solution, or crazy.
Right. Python code isn't likely to care about the specific version,
but binary extensions might.
Michael Barton wrote:
The important thing is that additional libraries like wxpython and
matplotlib get installed for the default version, whatever that is.
We
want to make sure that a script is running the same python that you
get when you type "python" from the command line. If you *want* to
run
it through a different python, you should just be able to use: [path
to desired python] myscript.py.
So what is the best way to make sure that the 'default' python is
used
in a script?
If by "default", you mean "first in $PATH", then use the /usr/bin/env
trick.
Of course, there's no guarantee that $PATH will be the same in all
contexts. E.g. if you modify PATH in ~/.bash_profile, you may get a
different result when running a script from a terminal compared to
running the same script from a GUI application.
If you want to guarantee consistency above all else, use
#!/usr/bin/python in the script. But then we would need to process
such scripts during installation (e.g. MSys doesn't have
/usr/bin/python, and it doesn't have symlinks so you can't just make
/usr/bin/python a symlink to the actual program).
--
Glynn Clements <[EMAIL PROTECTED]>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
