-
assigned issue to
- changed component to Build/install scripts
- changed version to Development Branch
./install script doesn't respect UPCXX_PYTHON fully
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 .
Comments (8)
-
-
reporter As a side note, other scripts (afaik upcxx_run) also suffer from the same issue
-
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.
-
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. -
Pull request #109 fixes
install
to correctly honor$UPCXX_PYTHON
, even when$PATH
contains something calledpython
that doesn't work for whatever reason.Installed scripts are a different problem. The installed
upcxx-run
script does currently assume the firstpython
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 thatupcxx-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. -
- changed status to resolved
Fix issue
#243: Honor$UPCXX_PYTHON
during install→ <<cset 297551cc0ccf>>
-
Merge pull request #109 into develop
→ <<cset 1403cb63b183>>
-
fixup: Fix issue
#243: Honor$UPCXX_PYTHON
du...This commit resolves a regression which would occur when
pwd
andpwd -P
do not agree (presumably because of hashing of full paths names by nobs).→ <<cset d419aef45e54>>
- Log in to comment
Hi @Alexander Ding - thanks for bringing this to our attention.
I'll look into addressing it.