./install script doesn't respect UPCXX_PYTHON fully

[Alexander Ding]

In the first part of the sourceme script, it directly runs NOBS_ROOT="$(python -c 'import os; import sys; sys.stdout.write(os.path.abspath(os.getcwd()));')". Likewise, the function absify makes direct use of the command python. Instead, the script should first find the correct shell .

[Dan Bonachea]

Hi @Alexander Ding - thanks for bringing this to our attention.

I'll look into addressing it.

[Alexander Ding]

As a side note, other scripts (afaik upcxx_run) also suffer from the same issue

[john bachan]

So long the way python is being used is compatible with all versions we could ever dream of encountering (like 2. 6 and above) then I don't think UPCXX_PYTHON is strictly necessary. For instance I believe NOBS_ROOT and absify are pretty benign. Still worth auditing for though.

[Paul Hargrove]

If we want to (and I am not sure we do) handle the possibility that python found first in $PATH is genuinely unusable (doesn't run at all), then significant changes would be required in some places.

For the case of installed scripts, we do have the option of substituting in the install-time value of $UPCXX_PYTHON in the #! line if we want to make them slightly more robust.

[Dan Bonachea]

Pull request #109 fixes install to correctly honor $UPCXX_PYTHON, even when $PATH contains something called python that doesn't work for whatever reason.

Installed scripts are a different problem. The installed upcxx-run script does currently assume the first python in $PATH is a functional python interpreter (any version), which it then uses for some carefully written bootstrap code that honors $UPCXX_PYTHON to find a suitable python2 for running the rest of the script. I'm with John on this one - I think that's a reasonable expectation and users can easily fix their $PATH if necessary (or directly invoke their chosen python and pass in the script).

@Paul Hargrove: Assuming the python used by the installing admin is also available to and functional for the end user at job spawn is IMHO significantly more problematic than relying on the user $PATH - there are many reasons this could fail, including insufficient permissions, file system rearrangement, or even that upcxx-run is executing on a compute node with a completely different file system. For all these reasons, using the python from $PATH is more likely to work, and gives an unprivileged user permission to fix any problem that might arise. If we really felt it was important to provide something more robust it would probably be a bourne-shell wrapper script that finds a suitable python to exec upcxx-run, but that seems like overkill at this point.

[Dan Bonachea]

Fix issue #243: Honor $UPCXX_PYTHON during install

→ <<cset 297551cc0ccf>>

[Dan Bonachea]

Merge pull request #109 into develop

• issue243-bad-python: Update ChangeLog Fix issue #243: Honor $UPCXX_PYTHON during install

→ <<cset 1403cb63b183>>

[Paul Hargrove]

fixup: Fix issue #243: Honor $UPCXX_PYTHON du...

This commit resolves a regression which would occur when pwd and pwd -P do not agree (presumably because of hashing of full paths names by nobs).

→ <<cset d419aef45e54>>