Python and frontendlauncher

Since the conversion to Python, several reports of startup errors with frontendlauncher and the user's system Python have been reported. These failures are likely due to a few causes:

  • Using an incompatible Python (like and old Python 2 or a Python 3.x)
  • Something in the user's environment is sabotaging Python's ability to locate modules

Typical error when Python 3 is used:

$ ./visit
Traceback (most recent call last):
  File "/home/user/visitfelpython1881", line 241, in <module>
  File "/home/user/visitfelpython1881", line 70, in ParseVersion
AttributeError: 'module' object has no attribute 'find'

There are some other more mysterious errors that happen. Could these have to do with how Python was built? Maybe that Python has no intrinsic notion of where to locate its modules. If that was true, unsetting the PYTHONHOME variable as we do in frontendlauncher would remove its ability to locate any modules.

There's also evidence that some distros are a little broken wrt python:

Running: gui2.6.1
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Traceback (most recent call last):
File "/home/user/visitfelpython8513", line 2, in <module>
  import os
ImportError: No module named os

Possible solution

Since we're reasonably confident in our Python that we're using, we can make frontendlauncher use VisIt's Python instead of system Python.

Benefits:

  • We know which version of Python will be used
  • We can possibly just use #!/path/to/visit/current/platform/bin/python as the top line of the launcher, avoiding temporary files

There are some drawbacks:

  • We introduce a version-specific Python into frontendlauncher (although the current link could be used)
  • When multiple binary distributions are colocated, we need to know the platform before invoking Python

Top of frontendlauncher

The top of frontendlauncher currently contains shell scripting code to find Python, write a file with the remainder of the script, and invoke the script. In addition, the script unsets PYTHONHOME to avoid any user or version sabotage of our Python.

  • We probably need to retain the code to unset the environment
  • We need to do a cursory check for the platform to use the right Python interpreter (this is for supporting co-located platform binaries)

Both of these issues mean that we probably need to retain a shell-based header in frontendlauncher on

MacOS X

On Mac, we can't hardcode a full path to the interpreter when we use a bundle so we'll have to do some shell scripting to do something like this: $(dirname $0)/../current/darwin-x86_64/bin/python for the path to Python.

Exec Python

There is a line in the shell header of frontendlauncher that looks like this:

exec python $TMPDIR/visitfelpython$$ $0 ${1+"$@"}

We can probably change it to:

# Add some code to set $platform
exec $(dirname $0)../current/$platform/bin/python $TMPDIR/visitfelpython$$ $0 ${1+"$@"}