Cannot resolve the configuration path in settings.json #627
Comments
|
Can you provide the logs using the following VS Code settings? {
"ruff.trace.server": "messages",
"ruff.logLevel": "debug"
} |
Have you opened the editor in the system root directory? If so, then the extension would traverse the entire system to collect all the configuration that are present in the nested directories and it could happen that one or the other configuration file is invalid. |
I think I get it. When opening a single file instead of a folder, Ruff cannot find the workspace and can only use workspace |
|
Same issue here. Interestingly, I tried reverting to previous versions of the extension but the problem is also there. |
This is not exactly true. The client is responsible for providing the workspace, so in your case, the client wasn't able to find any workspace. This leads to Ruff using the current working directory as the default workspace which in your case seems to be the system root directory ( Can you provide the log messages after turning them on to diagnose the error notification that you received?
@ffisc Please provide any log messages if possible to help diagnose the issue. |
However, when I open the folder containing the file, it finds the correct workspace and works fine. Here is the entire log. log |
I think that is an expected behavior. Thanks for providing the logs although I don't see any error messages in it. As mentioned, I think you were opening the editor in the system root directory which means it would take some time to load the extension completely because it tries to index the entire root directory. I'm really curious to know why the error is occurring although I'm mostly sure that one of the config on your system is invalid :) |
|
I can reproduce this behavior.
Ruff ends up indexing the entire root partition. This is unlikely what the user wanted. I don't have a good suggestion on what the extension should do in this case. What are other extensions doing in this case? |
|
And that file is in the root directory, right? This is related to astral-sh/ruff#11366 then. One solution would be to not index the workspace if there's none provided aka using the server for single file. Any nested configs shouldn't affect the output for this specific file. |
|
No. The file is in a subdirectory of my home directory |
Sure, here: |
Yeah, it seems that the client doesn't provide any workspace path during initialization and thus Ruff uses the current working directory but that turns out to be the root path ( |
|
So, there must be some config file that's invalid as per the |
I'll need to look into what other language servers are doing but one potential solution is #627 (comment). We would avoid traversing into the current working directory if the server is running in single-file mode. A single-file mode is basically when there's no workspace provided by the client. So, the indexer would still climb up as well as look into the current working directory for any config but it won't traverse it. |
|
I'm moving this discussion over to astral-sh/ruff#11366 as that's basically the root cause for it. |
This was referenced Oct 10, 2024
dhruvmanila
added a commit
to astral-sh/ruff
that referenced
this issue
Oct 18, 2024
## Summary This PR updates the language server to avoid indexing the workspace for single-file mode. **What's a single-file mode?** When a user opens the file directly in an editor, and not the folder that represents the workspace, the editor usually can't determine the workspace root. This means that during initializing the server, the `workspaceFolders` field will be empty / nil. Now, in this case, the server defaults to using the current working directory which is a reasonable default assuming that the directory would point to the one where this open file is present. This would allow the server to index the directory itself for any config file, if present. It turns out that in VS Code the current working directory in the above scenario is the system root directory `/` and so the server will try to index the entire root directory which would take a lot of time. This is the issue as described in astral-sh/ruff-vscode#627. To reproduce, refer astral-sh/ruff-vscode#627 (comment). This PR updates the indexer to avoid traversing the workspace to read any config file that might be present. The first commit (8dd2a31) refactors the initialization and introduces two structs `Workspaces` and `Workspace`. The latter struct includes a field to determine whether it's the default workspace. The second commit (61fc39b) utilizes this field to avoid traversing. Closes: #11366 ## Editor behavior This is to document the behavior as seen in different editors. The test scenario used has the following directory tree structure: ``` . ├── nested │ ├── nested.py │ └── pyproject.toml └── test.py ``` where, the contents of the files are: **test.py** ```py import os ``` **nested/nested.py** ```py import os import math ``` **nested/pyproject.toml** ```toml [tool.ruff.lint] select = ["I"] ``` Steps: 1. Open `test.py` directly in the editor 2. Validate that it raises the `F401` violation 3. Open `nested/nested.py` in the same editor instance 4. This file would raise only `I001` if the `nested/pyproject.toml` was indexed ### VS Code When (1) is done from above, the current working directory is `/` which means the server will try to index the entire system to build up the settings index. This will include the `nested/pyproject.toml` file as well. This leads to bad user experience because the user would need to wait for minutes for the server to finish indexing. This PR avoids that by not traversing the workspace directory in single-file mode. But, in VS Code, this means that per (4), the file wouldn't raise `I001` but only raise two `F401` violations because the `nested/pyproject.toml` was never resolved. One solution here would be to fix this in the extension itself where we would detect this scenario and pass in the workspace directory that is the one containing this open file in (1) above. ### Neovim **tl;dr** it works as expected because the client considers the presence of certain files (depending on the server) as the root of the workspace. For Ruff, they are `pyproject.toml`, `ruff.toml`, and `.ruff.toml`. This means that the client notifies us as the user moves between single-file mode and workspace mode. #13770 (comment) ### Helix Same as Neovim, additional context in #13770 (comment) ### Sublime Text **tl;dr** It works similar to VS Code except that the current working directory of the current process is different and thus the config file is never read. So, the behavior remains unchanged with this PR. #13770 (comment) ### Zed Zed seems to be starting a separate language server instance for each file when the editor is running in a single-file mode even though all files have been opened in a single editor instance. (Separated the logs into sections separated by a single blank line indicating 3 different server instances that the editor started for 3 files.) ``` 0.000053375s INFO main ruff_server::server: No workspace settings found for file:///Users/dhruv/projects/ruff-temp, using default settings 0.009448792s INFO main ruff_server::session::index: Registering workspace: /Users/dhruv/projects/ruff-temp 0.009906334s DEBUG ruff:main ruff_server::resolve: Included path via `include`: /Users/dhruv/projects/ruff-temp/test.py 0.011775917s INFO ruff:main ruff_server::server: Configuration file watcher successfully registered 0.000060583s INFO main ruff_server::server: No workspace settings found for file:///Users/dhruv/projects/ruff-temp/nested, using default settings 0.010387125s INFO main ruff_server::session::index: Registering workspace: /Users/dhruv/projects/ruff-temp/nested 0.011061875s DEBUG ruff:main ruff_server::resolve: Included path via `include`: /Users/dhruv/projects/ruff-temp/nested/nested.py 0.011545208s INFO ruff:main ruff_server::server: Configuration file watcher successfully registered 0.000059125s INFO main ruff_server::server: No workspace settings found for file:///Users/dhruv/projects/ruff-temp/nested, using default settings 0.010857583s INFO main ruff_server::session::index: Registering workspace: /Users/dhruv/projects/ruff-temp/nested 0.011428958s DEBUG ruff:main ruff_server::resolve: Included path via `include`: /Users/dhruv/projects/ruff-temp/nested/other.py 0.011893792s INFO ruff:main ruff_server::server: Configuration file watcher successfully registered ``` ## Test Plan When using the `ruff` server from this PR, we see that the server starts quickly as seen in the logs. Next, when I switch to the release binary, it starts indexing the root directory. For more details, refer to the "Editor Behavior" section above.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
The ruff extension could not resolve the configuration path set in the
settings.jsonsuddenly.During the initialization of ruff, the following error appeared:
Error while resolving settings from workspace /. Please refer to the logs for more details.Here is the log.
Version
Ruff: 0.6.6 (v2024.50.0)
VSCode: 1.94
The text was updated successfully, but these errors were encountered: