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

Provide an option to not change the selected interpreter when it doesn't exist #22523

Open
brettcannon opened this issue Nov 24, 2023 · 4 comments
Assignees
Labels
area-environments Features relating to handling interpreter environments community ask Feature request that the community expressed interest in feature-request Request for new features or functionality needs PR Ready to be worked on

Comments

@brettcannon
Copy link
Member

As noted by @ambv and @pablogsal in episode 3 of their core.py podcast, it's problematic when you select a Python interpreter that you're actively developing as the interpreter to use. This is because when you rebuild Python it will eventually delete the interpreter. The deletion triggers the extension to immediately look for another interpreter to fill in the gaps. This causes issue for Python core developers when they try to navigate to code and they end up in some installed interpreter's stdlib instead of the one they are actively working on.

Probably some setting that doesn't automatically switch the selected interpreter even if it doesn't exist would solve the issue. That way we can just pick back up when it exists again and just continue on working.

@brettcannon brettcannon added the feature-request Request for new features or functionality label Nov 24, 2023
@github-actions github-actions bot added the triage-needed Needs assignment to the proper sub-team label Nov 24, 2023
@cwebster-99 cwebster-99 added the needs community feedback Awaiting community feedback label Nov 27, 2023
Copy link

Thanks for the feature request! We are going to give the community 60 days from when this issue was created to provide 7 👍 upvotes on the opening comment to gauge general interest in this idea. If there's enough upvotes then we will consider this feature request in our future planning. If there's unfortunately not enough upvotes then we will close this issue.

@cwebster-99 cwebster-99 removed the triage-needed Needs assignment to the proper sub-team label Nov 27, 2023
@ambv
Copy link

ambv commented Nov 27, 2023

Yes, that would be great. The reason why this is important is that clicking through to definition of standard libraries for regular users opens the relevant installed Python file somewhere on the user's disk.

In our core development case, we want to click through to another file in the same checkout we are using. We are developing the standard libraries, so we expect all those files to be local. This works when the chosen interpreter is the one we built ourselves. But we rebuild it often so it can disappear momentarily. In this case we'd like the clickthrough to definition to still work because those files are still all there, it's just ./python.exe that is temporarily missing.

@brettcannon
Copy link
Member Author

I'm also assuming that Pylance is getting this from us, and so this is not something to ask downstream to change.

@brettcannon brettcannon added needs PR Ready to be worked on area-environments Features relating to handling interpreter environments community ask Feature request that the community expressed interest in and removed needs community feedback Awaiting community feedback labels Feb 22, 2024
@brettcannon
Copy link
Member Author

Because this is specific for the Python development team, we are granting an exception for the upvote requirement and are going to keep this open.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-environments Features relating to handling interpreter environments community ask Feature request that the community expressed interest in feature-request Request for new features or functionality needs PR Ready to be worked on
Projects
None yet
Development

No branches or pull requests

4 participants