python: Respect user settings for toolchain discovery over the toolchain set in Zed - #48262
Merged
osiewicz merged 1 commit intoApr 27, 2026
Merged
Conversation
…ain set in Zed Closes #46754
cla-bot
Bot
added
the
cla-signed
osiewicz
deleted the
pyright-basedpyright-respect-user-settings-for-toolchains
branch
April 27, 2026 08:43
zed-zippy
Bot
added
the
PR state:needs review
Member
|
@zed-zippy approved |
zed-zippy
Bot
removed
the
PR state:needs review
ebaah46
pushed a commit
to ebaah46/zed
that referenced
this pull request
May 6, 2026
…ain set in Zed (zed-industries#48262) Closes zed-industries#46754 Release Notes: - python: User settings now take precedence over toolchain set in Zed for pyright/basedpyright
kathbigra
pushed a commit
to kathbigra/zed
that referenced
this pull request
May 10, 2026
…ain set in Zed (zed-industries#48262) Closes zed-industries#46754 Release Notes: - python: User settings now take precedence over toolchain set in Zed for pyright/basedpyright
5 tasks
chirivelli
pushed a commit
to chirivelli/zed
that referenced
this pull request
Jul 15, 2026
…gured (zed-industries#59990) # Objective Closes zed-industries#55936 Helps zed-industries#57288 There is a strange behavior for Python users when using basedpyright or pyright as the language server. As reported in zed-industries#55936, when no settings are configured in `lsp.basedpyright.settings`, the language server correctly receives toolchain information discovered by Zed: ```json { "venvPath": ".", "venv": ".venv", "python": { "pythonPath": "/home/xin/works/test/test_python/.venv/bin/python", "defaultInterpreterPath": "/home/xin/works/test/test_python/.venv/bin/python" }, "basedpyright.analysis": { "typeCheckingMode": "standard" }, "basedpyright.disableOrganizeImports": true } ``` However, when the user configures any other settings in `lsp.basedpyright.settings`, the toolchain information is silently lost. For example, with the following `settings.json`: ```jsonc { "lsp": { "basedpyright": { "settings": { "analysis": { "diagnosticMode": "workspace", "typeCheckingMode": "standard", "inlayHints.callArgumentNames": true, "inlayHints.variableTypes": true, }, }, } } } ``` The final configuration sent to the language server becomes: ```json { "analysis": { "diagnosticMode": "workspace", "typeCheckingMode": "standard", "inlayHints.callArgumentNames": true, "inlayHints.variableTypes": true } } ``` No toolchain information is passed, so the language server ignores the user's selected Python environment and falls back to whatever virtual environment it discovers on its own. To make toolchain selection work, users currently have to manually configure virtual environment settings themselves (as noted in zed-industries#57288 (comment)). This issue was introduced in zed-industries#48262, which aimed to make the virtual environment used by basedpyright/pyright configurable. The core logic is the `should_insert_toolchain` closure, originally designed to check whether Zed should inject the detected toolchain into the language server configuration. The intent was: if the user has already configured a virtual environment in the language server settings, skip the injection. https://github.com/zed-industries/zed/blob/2c346f60a76fe3f0367ef924927f50a6efdf5718/crates/languages/src/python.rs#L2115-L2128 However, the original logic was inverted — it injected the toolchain when the user had no settings at all or when they had configured virtual environment keys. This meant that when the user had LSP settings but no virtual environment configuration, toolchain injection was skipped, as reported in zed-industries#55936. ## Solution Change the logic defined in `should_insert_toolchain` closure, instead of insert toolchain when detected virtual environment settings, now we insert toolchain when no virtual environment settings is detected. ## Testing Tested locally. The logic change is simple, should be easy for review. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed toolchain selection being ignored when Pyright or Basedpyright settings are configured without specifying a Python interpreter path
jonx
pushed a commit
to jonx/zed-aros
that referenced
this pull request
Jul 17, 2026
…ain set in Zed (zed-industries#48262) Closes zed-industries#46754 Release Notes: - python: User settings now take precedence over toolchain set in Zed for pyright/basedpyright
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
…ain set in Zed (zed-industries#48262) Closes zed-industries#46754 Release Notes: - python: User settings now take precedence over toolchain set in Zed for pyright/basedpyright
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
…gured (zed-industries#59990) # Objective Closes zed-industries#55936 Helps zed-industries#57288 There is a strange behavior for Python users when using basedpyright or pyright as the language server. As reported in zed-industries#55936, when no settings are configured in `lsp.basedpyright.settings`, the language server correctly receives toolchain information discovered by Zed: ```json { "venvPath": ".", "venv": ".venv", "python": { "pythonPath": "/home/xin/works/test/test_python/.venv/bin/python", "defaultInterpreterPath": "/home/xin/works/test/test_python/.venv/bin/python" }, "basedpyright.analysis": { "typeCheckingMode": "standard" }, "basedpyright.disableOrganizeImports": true } ``` However, when the user configures any other settings in `lsp.basedpyright.settings`, the toolchain information is silently lost. For example, with the following `settings.json`: ```jsonc { "lsp": { "basedpyright": { "settings": { "analysis": { "diagnosticMode": "workspace", "typeCheckingMode": "standard", "inlayHints.callArgumentNames": true, "inlayHints.variableTypes": true, }, }, } } } ``` The final configuration sent to the language server becomes: ```json { "analysis": { "diagnosticMode": "workspace", "typeCheckingMode": "standard", "inlayHints.callArgumentNames": true, "inlayHints.variableTypes": true } } ``` No toolchain information is passed, so the language server ignores the user's selected Python environment and falls back to whatever virtual environment it discovers on its own. To make toolchain selection work, users currently have to manually configure virtual environment settings themselves (as noted in zed-industries#57288 (comment)). This issue was introduced in zed-industries#48262, which aimed to make the virtual environment used by basedpyright/pyright configurable. The core logic is the `should_insert_toolchain` closure, originally designed to check whether Zed should inject the detected toolchain into the language server configuration. The intent was: if the user has already configured a virtual environment in the language server settings, skip the injection. https://github.com/zed-industries/zed/blob/3034ad945ae10a6a61758eb07dc1b0b1ef295270/crates/languages/src/python.rs#L2115-L2128 However, the original logic was inverted — it injected the toolchain when the user had no settings at all or when they had configured virtual environment keys. This meant that when the user had LSP settings but no virtual environment configuration, toolchain injection was skipped, as reported in zed-industries#55936. ## Solution Change the logic defined in `should_insert_toolchain` closure, instead of insert toolchain when detected virtual environment settings, now we insert toolchain when no virtual environment settings is detected. ## Testing Tested locally. The logic change is simple, should be easy for review. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed toolchain selection being ignored when Pyright or Basedpyright settings are configured without specifying a Python interpreter path
playdohface
pushed a commit
to playdohface/zed
that referenced
this pull request
Aug 29, 2026
…gured (zed-industries#59990) # Objective Closes zed-industries#55936 Helps zed-industries#57288 There is a strange behavior for Python users when using basedpyright or pyright as the language server. As reported in zed-industries#55936, when no settings are configured in `lsp.basedpyright.settings`, the language server correctly receives toolchain information discovered by Zed: ```json { "venvPath": ".", "venv": ".venv", "python": { "pythonPath": "/home/xin/works/test/test_python/.venv/bin/python", "defaultInterpreterPath": "/home/xin/works/test/test_python/.venv/bin/python" }, "basedpyright.analysis": { "typeCheckingMode": "standard" }, "basedpyright.disableOrganizeImports": true } ``` However, when the user configures any other settings in `lsp.basedpyright.settings`, the toolchain information is silently lost. For example, with the following `settings.json`: ```jsonc { "lsp": { "basedpyright": { "settings": { "analysis": { "diagnosticMode": "workspace", "typeCheckingMode": "standard", "inlayHints.callArgumentNames": true, "inlayHints.variableTypes": true, }, }, } } } ``` The final configuration sent to the language server becomes: ```json { "analysis": { "diagnosticMode": "workspace", "typeCheckingMode": "standard", "inlayHints.callArgumentNames": true, "inlayHints.variableTypes": true } } ``` No toolchain information is passed, so the language server ignores the user's selected Python environment and falls back to whatever virtual environment it discovers on its own. To make toolchain selection work, users currently have to manually configure virtual environment settings themselves (as noted in zed-industries#57288 (comment)). This issue was introduced in zed-industries#48262, which aimed to make the virtual environment used by basedpyright/pyright configurable. The core logic is the `should_insert_toolchain` closure, originally designed to check whether Zed should inject the detected toolchain into the language server configuration. The intent was: if the user has already configured a virtual environment in the language server settings, skip the injection. https://github.com/zed-industries/zed/blob/2c346f60a76fe3f0367ef924927f50a6efdf5718/crates/languages/src/python.rs#L2115-L2128 However, the original logic was inverted — it injected the toolchain when the user had no settings at all or when they had configured virtual environment keys. This meant that when the user had LSP settings but no virtual environment configuration, toolchain injection was skipped, as reported in zed-industries#55936. ## Solution Change the logic defined in `should_insert_toolchain` closure, instead of insert toolchain when detected virtual environment settings, now we insert toolchain when no virtual environment settings is detected. ## Testing Tested locally. The logic change is simple, should be easy for review. ## Self-Review Checklist: - [x] I've reviewed my own diff for quality, security, and reliability - [x] Unsafe blocks (if any) have justifying comments - [x] The content adheres to Zed's UI standards ([UX/UI](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist) and [icon](https://github.com/zed-industries/zed/blob/main/crates/icons/README.md) guidelines) - [ ] Tests cover the new/changed behavior - [x] Performance impact has been considered and is acceptable --- Release Notes: - Fixed toolchain selection being ignored when Pyright or Basedpyright settings are configured without specifying a Python interpreter path
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
3 participants
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.
Closes #46754
Release Notes: