Repository navigation
🐛 fix(py_info): stop venv lookups rewriting each other's executable - #171
Merged
Merged
Conversation
resolve_to_system swaps a venv's info for the base interpreter's info, which
comes straight out of the in-process cache, and then writes the venv's
executable onto it. Every venv built on the same base, and the base itself,
get that one object back, so each lookup rewrites the executable of every
earlier result. A process running from a venv that looks up a second venv on
the same base then gets the second venv from get_interpreter("python") and
from PythonInfo.current_system(), and running that executable lands in the
wrong environment. Results yielded by iter_interpreters change after the fact
in the same way, and when the process runs from the base interpreter the
object is the one PythonInfo.current() returns.
resolve_to_system now copies the info before pointing it at the start
executable, whether the info came from from_exe or from the discover_exe walk,
since both hand back cached objects. When the executable already matches, the
same object comes back as before, so virtualenv's check that the interpreter
is PythonInfo.current() keeps working.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Looking up one venv rewrote the
executableof results from earlier lookups that share its base interpreter. 🐛 Afterget_interpreter("/path/to/vb/bin/python"), a result already returned for venvva, along withPythonInfo.current_system()(andPythonInfo.current()when running from the base), reportedvbas its executable, so running it started the wrong environment.iter_interpretershad the same problem across its yields. Once this merges, every result keeps the executable it was looked up with, on Linux and Windows.The interpreter cache hands every lookup of a base interpreter the same object, and resolving a venv to its base then wrote the venv's path onto that shared object, a behavior carried over from virtualenv in #28. Resolution now gives the caller its own shallow copy whenever the executable has to change, and leaves the cached object alone. When the executable already matches, it returns the cached object unchanged, so
get_interpreter(sys.executable) is PythonInfo.current()still holds for a base interpreter, an identity virtualenv relies on.