VSCode setting should be overriden by discovered toml #425
Comments
|
I think this needs some design work on the intended behavior (CC: @snowsignal). To me, the VS code settings taking precedence over the project settings seem reasonable, or at least I could see where the opposite behavior is the intended behavior. It also opens the question if this should apply to all options or only some (e.g. what if I configure an additional configuration?) But I agree that what you're asking for makes sense, too; ultimately, the experience between IDE and CLI should be consistent, and that is only guaranteed by giving the project. to a higher priority. |
|
My use case is that I have synchronised VSCode settings everywhere. I'd like to be able to open different projects which each contain a But yes, I do see why one might expect the VSCode setting to take precedence instead! |
|
I'd support having a flag in the extension that lets discovered configuration take precedence. We'll look into solving this as we work on configuration for the upcoming VSCode extension based on our new Rust-based LSP. |
…ect configuration (#11062) ## Summary This is a follow-up to #10984 that implements configuration resolution for editor configuration. By 'editor configuration', I'm referring to the client settings that correspond to Ruff configuration/options, like `preview`, `select`, and so on. These will be combined with 'project configuration' (configuration taken from project files such as `pyproject.toml`) to generate the final linter and formatter settings used by `RuffSettings`. Editor configuration takes priority over project configuration. In a follow-up pull request, I'll implement a new client setting that allows project configuration to override editor configuration, as per [this issue](astral-sh/ruff-vscode#425). ## Review guide The first commit, e38966d, is just doing re-arrangement so that we can pass the right things to `RuffSettings::resolve`. The actual resolution logic is in the second commit, 0eec9ee. It might help to look at these comments individually since the diff is rather messy. ## Test Plan For the settings to show up in VS Code, you'll need to checkout this branch: astral-sh/ruff-vscode#456. To test that the resolution for a specific setting works as expected, run through the following scenarios, setting it in project and editor configuration as needed: | Set in project configuration? | Set in editor configuration? | Expected Outcome | |-------------------------------|--------------------------------------------------|------------------------------------------------------------------------------------------| | No | No | The editor should behave as if the setting was set to its default value. | | Yes | No | The editor should behave as if the setting was set to the value in project configuration. | | No | Yes | The editor should behave as if the setting was set to the value in editor configuration. | | Yes | Yes (but distinctive from project configuration) | The editor should behave as if the setting was set to the value in editor configuration. | An exception to this is `extendSelect`, which does not have an analog in TOML configuration. Instead, you should verify that `extendSelect` amends the `select` setting. If `select` is set in both editor and project configuration, `extendSelect` will only append to the `select` value in editor configuration, so make sure to un-set it there if you're testing `extendSelect` with `select` in project configuration.
…er editor configuration (#11086) ## Summary This is intended to address astral-sh/ruff-vscode#425, and is a follow-up to #11062. A new client setting is now supported by the server, `prioritizeFileConfiguration`. This is a boolean setting (default: `false`) that, if set to `true`, will instruct the configuration resolver to prioritize file configuration (aka discovered TOML files) over configuration passed in by the editor. A corresponding extension PR has been opened, which makes this setting available for VS Code: astral-sh/ruff-vscode#457. ## Test Plan To test this with VS Code, you'll need to check out [the VS Code PR](astral-sh/ruff-vscode#457) that adds this setting. The test process is similar to #11062, but in scenarios where the editor configuration would take priority over file configuration, file configuration should take priority.
) ## Summary Fixes #425 (though only in the pre-release version, since this is a feature for the new LSP server) This is a follow-up to #456. A new setting has been introduced, `Prioritize File Configuration`, which tells the extension to prioritize settings from discovered TOML files over extension settings. Extension settings will still be used when a set field in the extension is not set in the file configuration. ## Test Plan Refer to astral-sh/ruff#11086 for a test plan.
) ## Summary Fixes #425 (though only in the pre-release version, since this is a feature for the new LSP server) This is a follow-up to #456. A new setting has been introduced, `Prioritize File Configuration`, which tells the extension to prioritize settings from discovered TOML files over extension settings. Extension settings will still be used when a set field in the extension is not set in the file configuration. ## Test Plan Refer to astral-sh/ruff#11086 for a test plan.
|
This is possible now with the new |
Thanks for this. I would recommend changing it to be the default. With this Ruff extension, I was confused and surprised and had trouble figuring out what was going on. |
In addition to change ruff-vscode, here is the native server related code that needs to be changed: |
I've opened astral-sh/ruff#13067 to track that. |
Currently, extension settings override those which would be picked up in a
pyproject.toml/ruff.toml.This was highlighted in #3:
This is still the case (in my testing), but I'm surprised not to see another issue covering this (happy to be corrected!)
I think there should at least be an issue to track this one.
Environment
v2024.16.0(ruff==0.3.1)1.87.2Ubuntu 22.04.4Tested simply with
line-length = 120inruff.toml, and--line-length=120in VSCode settingruff.lint.argsThe text was updated successfully, but these errors were encountered: