-
Notifications
You must be signed in to change notification settings - Fork 61
Reset ruff.configuration
if it contains VS Code variables
#746
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
base: main
Are you sure you want to change the base?
Conversation
5acb913
to
ea1167d
Compare
Another thing I noted is that we could call |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if the extension should fail in that case instead of reverting to a default configuration. Just to be safe and the log message will guide users towards taking the right action. This is, from what I understand, also the closest to the current behavior.
What was your motivation for returning none
instead?
|
||
let configuration = getGlobalValue<string | object | null>(config, "configuration", null); | ||
if (typeof configuration === "string" && configuration.search(/\$\{workspaceFolder/) !== -1) { | ||
logger.info( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we log this with warn
or even error?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think so, it's not a user error but just something to note of. Refer to my other comment.
I don't think the extension can fail because it's not a user error. We're passing two settings to the language server - extension settings and global settings. The extension settings are computed for each workspace in the VS Code session while the global settings are computed by just considering the global values. Now, when a user has just specified a single |
I don't understand this part. I guess the situation I'm concerned about is that we're ignoring a setting explicitly set by the user (in one of their configuration file). Or is this not the case because the |
We're not ignoring any setting. The language server has access to settings specific to a workspace and the global settings. The global settings is used as a fallback if the workspace doesn't have a settings in the index. When this fallback happens, the server tries to resolve the settings which involves expanding any environment variables which is where the user sees this error. If the settings is used in the context of a workspace, the server will pickup the configuration to the path. This is a bit confusing because for VS Code, the workspace settings and the default settings (used to get the global settings value) are the same for a VS Code session with the single session unless the user has a workspace specific |
Summary
fixes: #741
Test Plan
settings.json
:"Ruff" output channel:
Note
I've only kept the necessary settings here but the actual log output includes everything
settings.json
:"Ruff" output channel:
For this specific test case, you can see that the workspace settings also includes the
${workspaceFolder:root}
because it doesn't exists. That would also create an error:I think we should handle that as well.