Repository: astral-sh/ruff-vscode

Issue #701: Consider `required-version` when finding the `ruff` binary
Created: 2025-02-22T09:08:57Z
Context
At our company, we configure the required-version to a specific allowed version in pyproject.toml like this:
[tool.ruff]
line-length = 150
required-version = "==0.9.3"
Issue
If you don't have ruff, or a different version installed, you get the following error notification:

   0.005164375s ERROR ThreadId(04) ruff_server::session::index::ruff_settings: Failed to resolve settings for /Users/kasperzutterman/Desktop/ruff_issue/pyproject.toml: Required version `==0.9.3` does not match the running version `0.9.7`

The above is great behaviour, however the extension falls back to the ruff version packaged with the extension, and skips the configuration defined by pyproject.toml.
This results in unintended formatting changes, that don't align with the company ruff configuration defined in pyproject.toml
Example
Below a minimal reproducible example:
Setup
# test.py

# Below line is 112 characters long, exceeding the  88 characters used as ruff default, but less than the line-length = 150 from pyproject.toml
example_line_too_long = ("value_1", "value_2", "value_3", "value_4", "value_5", "value_6", "value_7", "value_8")
With correct ruff version installed

uv venv --python=312
source .venv/bin/activate
uv pip install ruff==0.9.3
in vscode: >Ruff: format document

Result: no change, expected behaviour
Without ruff installed (or incorrect version)

in vscode: >Ruff: format document

Result: code reformatted, ignoring line-length = 150 defined by pyproject.toml
# Below line is 112 characters long, exceeding the  88 characters used as ruff default, but less than the line-length = 150 from pyproject.toml
example_line_too_long = (
    "value_1",
    "value_2",
    "value_3",
    "value_4",
    "value_5",
    "value_6",
    "value_7",
    "value_8",
)
Question

Is this the intended behaviour?
If Yes, is there any setting that can be used to prevent ruff from making any changes when no correct version is found?

Duplicate issue #711: Failure to parse `ruff.toml` results in default configuration
Created: 2025-02-28T19:48:41Z
When ruff.toml changes (e.g. git checkout) and the new contents are unparseable by the running Ruff server (e.g. addition of builtins-strict-checking with an already-running pre-0.9.6 Ruff server), the Ruff extension apparently just falls back to the default configuration and will still apply formatting changes, fixes, etc. disregarding ruff.toml. For us, this resulted in files being auto-formatted on save in ways that disagree with ruff.toml.
It seems to me that if ruff.toml fails to parse with the running Ruff server, the extension should at least try restarting it (in case the Ruff version launched by the ruff.path executable has been changed to cooperate with the changes to ruff.toml), and at the very least, it shouldn't go ahead with the default configuration. In other words, if there is a failure to parse ruff.toml, I never want the Ruff extension to ignore it and just try using the default configuration; I would want it to stop.

Closing comment (2025-03-04T16:26:00Z): It could make sense for us to store whether loading the configuration was successful or not and disable code actions (format on save, organize imports on save, etc) when that's true ( and show a message that the request was ignored because the configuration is broken.
A user can still format the document by manually requesting a Format document but that doesn't seem as problematic because the user explicitly requests to format the document.
I don't know how hard it is to implement this feature.

Yeah, I think that would be better. It's kind of related to #701 where we want something similar.