-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Native server indexes the entire project when no local config found #11366
Comments
@snowsignal I have more information, I think this revelation might make you want to close this issue? I had a hunch and moved the simple .py featured above from the location of It appears the issue is that formatting with ruff times out when the file is in the ~/ directory because it is busy parsing all of the sub-directories? |
I've ran into this as well, it's very confusing. The ruff Lsp would be delayed on startup if a modified python file is in a top level folder without a config file (i.e. outside of project directory). I noticed in Lsp logs that ruff is walking all subdirectories looking for a config file. I don't understand why ruff should be looking for a config file in subdirectories? Shouldn't it be the other way around i.e it should walk the parent directories to look for the config. This seems like a bug to me. Cc @dhruvmanila |
I think it has to scan sub folders in case you have a configuration e.g. only in the I wonder if we ignore directories like |
@MichaReiser - We ignore them now. We didn't in the initial beta release. |
I am confused. Surely if I am editing a file from outside the src/ directory, then even if you find a config there it shouldn't apply to the file I am editing, right? Right now if I am editing a python file in me $HOME, it seems to walk the entirety of my HOME which seems suboptimal:-) |
I'm looking into this. The Looking at the following logs, it does seem like we're traversing the entire home directory to build up the index which I think was intentional in #10950.
|
I don't think we're ignoring them. I just logged the directories that we're visiting and it is visiting the
|
Ok, we are ignoring the
And via a Python file in home directory:
I think what is happening is that the exclusion is using the existing index which is currently being built: ruff/crates/ruff_server/src/session/index/ruff_settings.rs Lines 145 to 147 in 25080ac
But, it doesn't contain the resolved settings until it encounters a configuration file and only then it'll start excluding any relevant directories for the matching paths. I think this is an expected behavior. |
There are two more options that could be implemented here:
|
## Summary This PR updates the server to build the settings index in parallel using similar logic as `python_files_in_path`. This should help with #11366 but ideally we would want to build it lazily. ## Test Plan `cargo insta test`
## Summary This PR updates the settings index building logic in the language server to consider the fallback settings for applying ignore filters in `WalkBuilder` and the exclusion via `exclude` / `extend-exclude`. This flow matches the one in the `ruff` CLI where the root settings is built by (1) finding the workspace setting in the ancestor directory (2) finding the user configuration if that's missing and (3) fallback to using the default configuration. Previously, the index building logic was being executed before (2) and (3). This PR reverses the logic so that the exclusion / `respect_gitignore` is being considered from the default settings if there's no workspace / user settings. This has the benefit that the server no longer enters the `.git` directory or any other excluded directory when a user opens a file in the home directory. Related to #11366 ## Test plan Opened a test file from the home directory and confirmed with the debug trace (removed in #12360) that the server excludes the `.git` directory when indexing.
Just wanted to say great job on improving this over the last few releases. This only takes ~10 seconds to successfully format compared to the ~2 minutes before...Same file, same directory, same repeated format "issues" and a vastly improved user experience now. |
I initially posted this in #11258 as an issue I noticed but I figured it was going to be fixed with the associated PR(#11266). However with ruff 0.4.4 I noticed that the problem described below still persists. I am going to attach the LSP error from neovim, it appears to have a lot of repeating messages so I apologize.
I am also going to copy and paste the lsp log from ~2 minutes later when I tried again in the same file (without closing it, just waiting ~ 2 minutes, and it successfully formatted.
The text was updated successfully, but these errors were encountered: