-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Changes to logic for selection of best (default) version of Python interpreter #3369
Comments
Requirement
Problems
Terminology
Solutions:
|
One thing we will need to help with debugging reported issues is a way for people to get to the path to the selected Python interpreter. Maybe a command to write it out to settings.json? |
Sounds like we need to create a command that'll spit out debug logs
Get all info and dump into clipboard or open an editor with all of that in there for user to copy and paste into the GitHub issue. |
This mostly worked for me on master. Instead of picking "python" as it used to, it picked
So it's not clear why it did not pick 3.7.1, nor why it preferred the virtualenv over conda or pyenv (for 3.7.0). I would have expected it to pick 3.7.1. In the face of a tie (as with 3.7.0) I would have expected it to ask me. All that said, picking 3.7.0 instead of 2.7 is an improvement. :) |
@ericsnowcurrently the order preference is venv, virtualenv, pipenv, global, conda; IOW this worked the way it's designed. The thinking is the first three options were on purpose and are directly tied to the workspace folder, and conda is last because (a) it isn't directly tied to a directory and (b) it's slow to detect 😁 . |
Related to #3326
Today we use
python
as the default version of Python for the extension.Logic for selection of best (default) version of Python interpreter:
The text was updated successfully, but these errors were encountered: