Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better handling of base executable not found #1515 #1522

Merged
merged 8 commits into from Jan 30, 2020

Conversation

gaborbernat
Copy link
Contributor

@gaborbernat gaborbernat commented Jan 29, 2020

Improve the base executable discovery mechanism:

  • print at debug level why we refuse some candidates,
  • when no candidates match exactly, instead of hard failing fallback to the closest match where the priority of matching attributes is python implementation, major version, minor version, architecture, patch version, release level and serial (this is to facilitate things to still work when the OS upgrade replace/upgrades the system python with a newer version than what the virtualenv host python was created with),
  • always resolve system_executable information during the interpreter discovery, and the discovered environment is the system interpreter instead of the venv/virtualenv (this happened before lazily the first time we accessed and caused reporting that the created virtual environment is of type of the virtualenv host python version, instead of the system pythons version - these two can differ if the OS upgraded the system python underneath and the virtualenv host was created via copy),

Resolves #1515.

@gaborbernat gaborbernat changed the title Interpreter failed to be found More gracious handling of base executable not found (fallback to closest one available) Jan 29, 2020
@gaborbernat gaborbernat changed the title More gracious handling of base executable not found (fallback to closest one available) Better handling of base executable not found (fallback to closest one available) Jan 29, 2020
Add debug message why we refuse an interprter found within
find_exe_based_of.

Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
…st matches instead of hard fail

Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
…nts us to

Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
Signed-off-by: Bernat Gabor <bgabor8@bloomberg.net>
@gaborbernat gaborbernat changed the title Better handling of base executable not found (fallback to closest one available) Better handling of base executable not found #1515 Jan 30, 2020
@gaborbernat gaborbernat merged commit 9d37eb3 into pypa:rewrite Jan 30, 2020
@gaborbernat gaborbernat deleted the 1515 branch January 30, 2020 18:53
encukou added a commit to encukou/tox-current-env that referenced this pull request Aug 11, 2020
…on run

Virtualenv 20.0 follows symlinks when populating sys.executable,
so we can't use it. (AFAIUI it's done to better handle cases where the
system executable is changed after a virtualenv is created.)
See: pypa/virtualenv#1522

sys.exec_prefix still points to inside the virtualenv, so use that
in the tests to determine what's being run.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants