-
Notifications
You must be signed in to change notification settings - Fork 1.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
ruff server
: Support Jupyter Notebook (*.ipynb
) files
#11206
Conversation
|
3a721e2
to
ef8727f
Compare
4fb4f0f
to
a8e00a6
Compare
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've left some comments to add context for a few parts of the code and also to remind myself to refactor a few things before we merge 🙂
a8e00a6
to
4ddd930
Compare
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've provided some initial comments and I plan to look at other changes soon. It's quite a big PR :)
It would be helpful if you could briefly enumerate all the changes made in the PR description. I'd especially find the list of refactoring useful. It would be also useful for posterity to provide any context on the reasoning behind the implementation and if there were any other solutions that you thought of but didn't implement it.
Can you also update the test plan with all the cases that you've tested this against? Ideally it could contain the VS Code settings used and the action performed (command, code action, etc.). There are so many VS Code settings, commands and code actions for Notebook 😅
crates/ruff_server/src/server.rs
Outdated
types::NotebookDocumentFilter::ByType { | ||
notebook_type: "jupyter-notebook".to_string(), | ||
scheme: Some("file".to_string()), | ||
pattern: None, | ||
}, |
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.
Is this specific to VS Code? I'm referring to the "jupyter-notebook" type. For reference, we don't use any notebook document filter in ruff-lsp
:
This asks to only send the request to sync the Python code cells as we aren't interested in any kind of cell.
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.
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 see. I'm not sure where does the jupyter-notebook
type comes from.
I assume this would be the same across editors.
I think it depends - If it is set by VS Code, then I don't think it would be same.
I don't think we need to worry about this now but, just to be on the safer side, I'd probably keep this same as ruff-lsp
.
Does this work on unsaved Notebook files? Like, a new notebook file is opened in VS Code but it doesn't exists on disk yet.
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.
Does this work on unsaved Notebook files? Like, a new notebook file is opened in VS Code but it doesn't exists on disk yet.
This does fail - I think it might be because an unsaved URL isn't a valid file path.
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.
Hmmm.... it seems like, in general, that the server doesn't support files created from Ctrl+N
in VS Code if they aren't saved to the file system. I'll create a follow-up issue for this.
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.
This does fail, but only because new notebook cell url gets passed into
didOpenTextDocument
, which isn't expected. Do we need to support 'unattached' notebook cells?
I just checked, we do support it. It's probably because we never touch the filesystem in ruff-lsp
and always work with stdin with ruff
command.
crates/ruff_server/src/server/api/notifications/did_open_notebook.rs
Outdated
Show resolved
Hide resolved
38f718d
to
8cb7d55
Compare
92c764a
to
eae6368
Compare
…ses cell boundaries
04b7e15
to
272f2fa
Compare
…#11492) ## Summary Recent changes made in the [Jupyter Notebook feature PR](#11206) caused automatic configuration reloading to stop working. This was because we would check for paths to reload using the changed path, when we should have been using the parent path of the changed path (to get the directory it was changed in). Additionally, this PR fixes an issue where `ruff.toml` and `.ruff.toml` files were not being automatically reloaded. Finally, this PR improves configuration reloading by actively publishing diagnostics for notebook documents (which won't be affected by the workspace refresh since they don't use pull diagnostics). It will also publish diagnostics for text documents if pull diagnostics aren't supported. ## Test Plan To test this, open an existing configuration file in a codebase, and make modifications that will affect one or more open Python / Jupyter Notebook files. You should observe that the diagnostics for both kinds of files update automatically when the file changes are saved. Here's a test video showing what a successful test should look like: https://github.com/astral-sh/ruff/assets/19577865/7172b598-d6de-4965-b33c-6cb8b911ef6c
## Summary This PR fixes a bug where the server wouldn't retain the cell content in case of a reorder change request. As mentioned in #12573 (comment), this change request is modeled as (a) remove these cell URIs and (b) add these cell URIs. The cell content isn't provided. But, the way we've modeled the `NotebookCell` (it contains the underlying `TextDocument`), we need to keep track of the deleted cells to get the content. This is not an ideal solution and a better long term solution would be to model it as per the spec but that is a big structural change and will affect multiple parts of the server. Modeling as per the spec would also avoid bugs like #11864. For context, that model would add complexity per #11206 (comment). fixes: #12573 ## Test Plan This video shows the before and after the bug is fixed: https://github.com/user-attachments/assets/2fcad4b5-f9af-4776-8640-4cd1fa16e325
Summary
Closes #10858.
ruff server
now supports*.ipynb
(aka Jupyter Notebook) files. Extensive internal changes have been made to facilitate this, which I've done some work to contextualize with documentation and an pre-review that highlights notable sections of the code.*.ipynb
cells should behave similarly to*.py
documents, with one major exception. The format commandruff.applyFormat
will only apply to the currently selected notebook cell - if you want to format an entire notebook document, useFormat Notebook
from the VS Code context menu.Test Plan
The VS Code extension does not yet have Jupyter Notebook support enabled, so you'll first need to enable it manually. To do this, checkout the
pre-release
branch and modifysrc/common/server.ts
as follows:Before:
After:
I recommend testing this PR with large, complicated notebook files. I used notebook files from this popular repository in my preliminary testing.
The main thing to test is ensuring that notebook cells behave the same as Python documents, besides the aforementioned issue with
ruff.applyFormat
. You should also test adding and deleting cells (in particular, deleting all the code cells and ensure that doesn't break anything), changing the kind of a cell (i.e. from markup -> code or vice versa), and creating a new notebook file from scratch. Finally, you should also test that source actions work as expected (and across the entire notebook).Note:
ruff.applyAutofix
andruff.applyOrganizeImports
are currently broken for notebook files, and I suspect it has something to do with #11248. Once this is fixed, I will update the test plan accordingly.