bugfix: make _source_single_file work in venvs#14569
Conversation
This reverts commit 808c80d.
…ile` (spack#14252)" This reverts commit 96063f9.
| # and read the JSON back in the parent process to update os.environ | ||
| module_cmd += ' > /dev/null; PYTHONHOME="{0}" "{1}" -c "{2}"'.format( | ||
| sys.prefix, sys.executable, py_cmd) | ||
| module_cmd += ' >/dev/null;' + sys.executable + ' -c %s' % py_cmd |
There was a problem hiding this comment.
@adamjstewart I'm not sure this needs changing, as probably it's always called before the modifications from packages are applied. Need to double check though.
|
Oops, I’ve never used venvs before, only Spack Envs. You could search for |
I don't think it's 100% bulletproof, but the reasoning in this PR is:
|
This is only true for |
|
Related to #11989. |
Now we search for `python3`, `python`, `python2` before resorting to `sys.executable`.
|
I think we should follow this on with some consideration of what we were trying to do with #11989 (i.e. we should remember the |
_source_single_file work in venvs
Using `sys.executable` to run Python in a sub-shell doesn't always work in a virtual environment as the `sys.executable` Python is not necessarily compatible with any loaded spack/other virtual environment. - revert use of sys.executable to print out subshell environment (#14496) - try instead to use an available python, then if there *is not* one, use `sys.executable` - this addresses RHEL8 (where there is no `python` and `PYTHONHOME` issue in a simpler way
See issue #14568
Currently unit tests for Spack don't run cleanly under
venvs. This aims at fixing the issue while not regressing on #14252 and #14491. Bonus if anybody could suggest a way to test this patch for all these issues.