Consider required-version when finding the ruff binary

[KasperZutterman]

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

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

Result: no change, expected behaviour

Without ruff installed (or incorrect version)

1. 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

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

[KasperZutterman]

Perhaps a third importStrategy as mentioned by this issue would help fix this: #655

[MichaReiser]

Thanks for the detailed write up.

I'm not sure if Ruff actually falls back to the bundled version but it does seem that it simply ignores the configuration in that case, which gives you the undesired result.

I worry, that it's slightly difficult to catch the version mismatch error in the server code only or, it may require some refactors to propagate the error code all the way back to the server.

[MichaReiser]

What's not entirely clear to me is what the expected behavior is. Is it that ruff emits an error but keeps linting/formatting or that ruff emits an error and the linter and formatter are turned off?

[KasperZutterman]

I would say the issue consists of 2 parts:

1. If no required-version match is found, the configuration should still be used when ruff emits an error but keeps linting/formatting.
2. Having the option to explicitly turn off ruff when no required-version match is found. (basically Add a strict version of fromEnvironment import strategy #655)

1. would fix the current fallback behaviour, which now results in incorrect ruff linting & formatting.
2. can be a future improvement to more explicitly indicate an incorrect/no version is installed.

[dhruvmanila]

1. If no required-version match is found, the configuration should still be used when ruff emits an error but keeps linting/formatting.

This will require parsing the pyproject.toml file and checking the required-version field. My main concern here is how to resolve the configuration, we don't want to replicate the resolver logic from Ruff so we could maybe consider just looking at the pyproject.toml file at the project root.

2. Having the option to explicitly turn off ruff when no required-version match is found. (basically Add a strict version of fromEnvironment import strategy #655)

I think you're correct that the linked issue will solve your use-case here but only partially. This is because the extension will throw an error as there was no ruff executable found in the environment (global or project's virtual environment) and not because of the required-version field. So, if there was a global ruff executable that doesn't match the required version, it won't throw an error.

I'm a bit hesitant to add logic to consider the required-version field.

[dhruvmanila]

(I don't consider this as bug but a feature request as I think it's currently working as intended)

[KasperZutterman]

@dhruvmanila I would argue this ticket is a bug, as the required-version documentation states:

If the version of Ruff does not meet the requirement, Ruff will exit with an error.
Useful for unifying results across many environments, e.g., with a pyproject.toml file.

And the usage is broken when using ruff-vscode, as it falls back to the bundled executable of the ruff binary. Also possibly using an entirely different ruff configuration, as it doesn't honor the other rules defined next to the required-version.

[dhruvmanila]

I think there's a misunderstanding of what required-version means. That setting is specific to Ruff and not related to how the extension tries to find the ruff binary. What we're talking about here and the importStrategy setting is related to the extension behavior.

And the usage is broken when using ruff-vscode, as it falls back to the bundled executable of the ruff binary. Also possibly using an entirely different ruff configuration, as it doesn't honor the other rules defined next to the required-version.

Yes, but that's because the behavior is expected at the extension level. What happens is that the extension tries to find the ruff binary to use based on the extension settings and it didn't find a ruff binary in the environment so it falls back to using the bundled executable. Here, the server is then started using this binary which then resolves the setting and considers the executable unusable because of the version mismatch.

Writing that out explicitly made me think that the fix should be at the server level where we should handle this specific error explicitly by:

1. Notifying the users about the version mismatch
2. Setting a flag in the server to not provide any functionalities (linting, formatting, code actions, etc.). Basically, disable the server but not shutdown.

[dhruvmanila]

(My previous comment is mostly me thinking out loud :))