Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VSCode setting should be overriden by discovered toml #425

Open
Tracked by #480
celynw opened this issue Mar 13, 2024 · 3 comments
Open
Tracked by #480

VSCode setting should be overriden by discovered toml #425

celynw opened this issue Mar 13, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@celynw
Copy link

celynw commented Mar 13, 2024

Currently, extension settings override those which would be picked up in a pyproject.toml/ruff.toml.
This was highlighted in #3:

Yeah, that's correct -- the pyproject.toml in the project path doesn't override the settings from the VS Code extension. Which is not ideal, for the reasons you described.

The best way to solve this today is to use a user-specific pyproject.toml rather than going through the VS Code extension. For example, if you're on macOS, you can create a pyproject.toml at ~/Library/Application\ Support/ruff/pyproject.toml. Then, when linting, if Ruff can't find a pyproject.toml in the current file path, it will use that as the default settings.

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

  • Ruff extension version v2024.16.0 (ruff==0.3.1)
  • VSCode version 1.87.2
  • OS: Ubuntu 22.04.4

Tested simply with line-length = 120 in ruff.toml, and --line-length=120 in VSCode setting ruff.lint.args

@dhruvmanila dhruvmanila added the enhancement New feature or request label Mar 18, 2024
@MichaReiser
Copy link
Member

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.

@celynw
Copy link
Author

celynw commented Mar 18, 2024

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!

@snowsignal
Copy link
Member

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.

@snowsignal snowsignal self-assigned this Mar 18, 2024
snowsignal added a commit to astral-sh/ruff that referenced this issue Apr 23, 2024
…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.
snowsignal added a commit to astral-sh/ruff that referenced this issue Apr 26, 2024
…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.
snowsignal added a commit that referenced this issue May 17, 2024
)

## 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.
snowsignal added a commit that referenced this issue May 17, 2024
)

## 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants