Ruff extension blocks pixi from working Windows

[melund]

I often run into a problem caused by the ruff-vscode extension when using pixi package manager on windows.

Pixi refuses to update the environment with the following error:

led to unlink python-3.12.4-h889d299_0_cpython.conda
  ╰─▶ failed to delete file: DLLs/_asyncio.pyd

The Windows process explorer reveals that this is caused by the ruff-extension which tries to use Python from the pixi environments.

Here is the commandline for the blocking process:

d:\..\.pixi\envs\..\python.exe c:\Users\mel\.vscode\extensions\charliermarsh.ruff-2024.42.0-win32-x64\bundled\tool\server.py

I think the ruff extension should refuse to use a Python.exe if it comes from a pixi environments. It just causes problems and it is really hard to figure out why Windows locks the DLLs.

Any Python versions install using pixi global would probably be OK. But otherwise, maybe only use globally installed Pythons.

I am using the vscode extension: v2024.42.0.

[MichaReiser]

Hmm, I don't think there's much we can do about this as it is inherent to window's file handling.

The "old" Ruff LSP that powers the extension is written in Python and it uses the Python environment selected in VS code to run it. You can manually override the Python interpreter by setting ruff.interpreter. Would that work for you?

Alternatively, you migrate to the new native server that runs a binary (without using Python). However, that can run into the same issues when ruff is installed into your local venv.

[melund]

Hmm, I don't think there's much we can do about this as it is inherent to window's file handling.

Well. I think the extension should never use a 'Python' from a pixi environment to run the server. Windows file-handling will make pixi unusable if you do.

Your other options will work fine for me as a workaround. But maybe consider changing the default behavior.

[MichaReiser]

Well. I think the extension should never use a 'Python' from a pixi environment to run the server. Windows file-handling will make pixi unusable if you do.

I'm not sure if that would be what other users expect. The convention for discovering a python installation is that the python installation in the venv takes precedence. That's why I think we should keep the default behavior as is and the extension has the necessary settings for users that want to always use the system python installation

[melund]

I'm not sure if that would be what other users expect.

That may also be true for most python virtual environments. But it breaks pixi. You literally can't run any pixi commands as soon as it wants to update the python package.

And it is very hard to figure out what process causes the problem. I had to use the "file locksmith" to figure out which process was blocking it, and then dig into what started it.

I guess pixi should come with better error messages when that happens. I did report that.

[dhruvmanila]

I think this issue won't be occurring with the new "native" server (ruff.nativeServer: "on") because it uses the Python executable only to get the ruff executable from the current environment which is a one-off command (lock will be released as soon as the command execution completes). While, ruff-lsp requires the Python executable to run the server so the lock will be held while the extension is active.