Handle both API versions #15932
Handle both API versions #15932
Conversation
| const dir = path.dirname(notebook.uri.fsPath); | ||
| // Note: Has to be different than the prefix for old notebook editor (HiddenFileFormat) so | ||
| // that the caller doesn't remove diagnostics for this document. | ||
| this._notebook = new SafeNotebookDocument(notebook); |
There was a problem hiding this comment.
@DonJayamanne This was more of my argument for using the wrapper in this case. When we are done with this, we just delete SafeNotebookDocument and set notebook back to NotebookDocument. Won't have to track down and worry about the 20 or so places that we access it. And old and new API can just use the same functions on it.
There was a problem hiding this comment.
Note, I have some cleanup and testing to do before submitting for review. Old comments and whatnot. Just putting it up for draft discussion.
| // In the Python extension we often need to support different changing | ||
| // VS Code api versions. This class adds a layer of indirection so that we | ||
| // can handle changes to the NotebookDocument class in the API | ||
| export class SafeNotebookDocument implements ISafeNotebookDocument { |
There was a problem hiding this comment.
Suggestion only: we can create a GitHub issue for deprecating this wrapper and reference it in the comment here so we don't forget to remove it.
There was a problem hiding this comment.
Agreed, if we move forward with this PR I'll add the issue. Just don't want to add it if we don't go with the wrapper class.
There was a problem hiding this comment.
Rather than using a new class you can use the ES6 Proxy object.
This way u dont need to implement each property or method.
Just override getCells, cellAt and cellCount
There was a problem hiding this comment.
But thats an optionally improvement, hence a non blocking susggestion.
Else LGTM
There was a problem hiding this comment.
Proxy totally looks like what I was searching for earlier today. I'm going to go ahead with this as the goal here is to just remove this code in a few releases. I filed this issue #5503 to remove it once 1.56 has been in stable for a release or two.
|
@kimadeline For context, was discussing this with @karthiknadig in the release branch PR. I had updated python side code to handle the newest VS Code notebook API, but realized that this would cause issues with the release (since VS Code is not on 1.56 yet) and also this would currently break the small number of customers using Native Notebooks + Python insiders + Stable vscode. Instead of forcing python to move to 1.56 I've updated the class here to handle either the old API or the new API. If we approve this approach will port to the release branch as well. |
|
Tested building python extension from main in both insiders and stable. Insiders followed the new API path and LS features worked in native notebooks. Stable followed the old cells path and LS feature worked. |
* Do not run `poetry env info -p` to get the type for local poetry environment (#15898) * Do not run poetry env info -p to get the type for local poetry environment, get best effort type instead * Update src/test/pythonEnvironments/common/envlayouts/poetry/project4/pyproject.toml Co-authored-by: Karthik Nadig <[email protected]> Co-authored-by: Karthik Nadig <[email protected]> * Handle both API versions (#15932) (#15936) * Correct a news item (#15904) * Use a more forgiving comparer when comparing version (#15912) * Use a more forgiving comparer when comparing version * Update tests * Move sort interpreters function * Wrap yields with a try catch (#15931) * Log parsing errors in verbose mode only * Fix conda logging * Wrap yields with try catch * Updating the version, change-log, and TPN for release (#15989) * Update TensorBoard launcher script to not use deprecated API (#15991) Co-authored-by: Kartik Raj <[email protected]> Co-authored-by: Ian Huff <[email protected]> Co-authored-by: Joyce Er <[email protected]>
Change the Notebook Language service code to handle either API >=1.56 and <1.56 so that python insiders will work on current stable vscode. Also will port to the release branch so that python extension can release without having to wait for vscode 1.56 to release to stable.