Open celynw opened 3 months ago
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 pyproject.toml
file. I either have to keep my 'master' synchronised Ruff VSCode settings empty, or I have to create a workspace settings file (under .vscode/settings.json
) explicitly setting those settings to be empty, overriding my 'master' synced settings and allowing the toml file to do something.
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.
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.2
Ubuntu 22.04.4
Tested simply with
line-length = 120
inruff.toml
, and--line-length=120
in VSCode settingruff.lint.args