Spyder 5 Language Server Selection Limits: No Per-Project Pinning or Automatic Fallback

Question

Spyder 5 replaced the legacy Jedi-based completion engine with a Language Server Protocol client, defaulting to python-lsp-server (pylsp) together with pyflakes, pycodestyle, mccabe and rope plugins. The "Completion and linting" preferences page allows enabling or disabling the LSP client, choosing a language server executable, and adjusting completion trigger characters and the completion delay, which defaults to 150 ms.

The open limitation concerns environments where several servers coexist, such as pylsp alongside pyright or jedi-language-server. As of Spyder 5.4–5.5, there is no documented preferences entry or config file key to prioritize or pin a specific server binary per project; selection appears to rely on entry-point registration and PATH ordering. In addition, if the selected server crashes or times out, Spyder does not automatically fall back to Jedi — the status widget reports the server as not running and a manual restart is required.

Is there a supported mechanism in Spyder 5.4–5.5 to pin one language server binary for a given project or interpreter? What exactly determines the selection order when multiple servers are discoverable? Is a manual restart from the LSP status widget the only documented recovery path after a server failure?

Tasadduq Burney · Answer

LSP Configuration Limits in Spyder 5.4–5.5
In Spyder 5.4 and 5.5, there is no supported mechanism to pin a specific language server binary to a particular project or Python interpreter. The Language Server Protocol (LSP) configuration is global; any change made in the preferences applies to all open files and projects regardless of the active environment.

Server Selection and Priority
The selection of the language server is determined by the following hierarchy:

Explicit Path: If a specific path to an executable is provided in Preferences > Completion and linting, Spyder uses that binary exclusively.
  Environment PATH: If no explicit path is set, Spyder relies on the system PATH and the entry-point registration of the installed packages in the current environment to locate a compatible server (defaulting to python-lsp-server).

Because the setting is global, you cannot automate the switching of servers when moving between projects with different requirements (e.g., switching from pylsp to pyright).

Recovery and Fallback Behavior
Spyder 5 does not implement an automatic fallback to the legacy Jedi engine if the LSP server crashes or times out. The LSP client and the legacy completion engine are treated as distinct modes of operation. If the server process terminates unexpectedly, the IDE will stop providing completions and linting until the server is revived.
The only documented recovery path is a manual restart via the LSP status widget located in the bottom status bar of the IDE.

Verification Steps
To verify your current configuration and behavior, you can perform the following:

Check Global Scope: Navigate to Preferences > Completion and linting. Change the server executable and observe that the change affects all open editors immediately after a server restart.
  Test Failure Recovery: Use a system monitor (e.g., Task Manager or htop) to force-kill the language server process. Observe that the status widget reports the server as not running and that completions cease until you manually trigger a restart from the widget.

Diagnostic Note: To provide a more specific workaround, please clarify if you are using a standalone Spyder installation or the Anaconda distribution, as this affects how the PATH is inherited by the LSP process.

Spyder 5 Language Server Selection Limits: No Per-Project Pinning or Automatic Fallback

1 answer

LSP Configuration Limits in Spyder 5.4–5.5

Server Selection and Priority

Recovery and Fallback Behavior

Verification Steps

Your perspective belongs here.

0 question comments