Blacklist __PYVENV_LAUNCHER__ env var in subprocess calls #46
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I encountered a weird bug in which the shebang in any binaries created using
venv.install
points to the wrong Python path, instead of the Python binary created within the virtualenv. It also seems that this bug is specific to macOS, or maybe just to Homebrew installs of Python.If I do the following:
Since
yapf
is not installed in the Homebrew Python's environment (based on the shebang), we get a ModuleNotFoundError.See pypa/virtualenv#845 for more details. It seems that this is a bug in CPython/pip itself (supposed fix at python/cpython#9516), but there hasn't been movement on either CPython or pip to fix it.
Either way, blacklisting the
__PYVENV_LAUNCHER__
environment variable before callingsubprocess.Popen
seems to be the fix adopted by most people in the interim; see wntrblm/nox#49 for an example.