Add remote mode for initial Remote Development compatibility#1861
Add remote mode for initial Remote Development compatibility#1861
Conversation
…TABRICKS_REMOTE_ENV=1 When running inside a Databricks Remote SSH session (DATABRICKS_REMOTE_ENV=1 and DATABRICKS_VIRTUAL_ENV set), the extension now activates in a minimal mode: it sets the Python virtual env path, registers a placeholder tree view, and disables all Databricks-specific commands/views/menus via the new `databricks.context.remoteMode` when-context. Co-authored-by: Isaac
| if (process.env["DATABRICKS_REMOTE_ENV"] === "1" && venvPath) { | ||
| customWhenContext.setRemoteMode(true); | ||
|
|
||
| await pythonExtensionWrapper.api.environments.updateActiveEnvironmentPath( |
There was a problem hiding this comment.
If the Python extension isn't installed or hasn't activated yet in the remote session, pythonExtensionWrapper.api could be undefined, causing a runtime crash. Worth adding a guard or try/catch here.
There was a problem hiding this comment.
We activate the extension in the initialization flow above (and don't even proceed with the initialization if python is not found)
| "submenu": "databricks.run", | ||
| "group": "navigation@0", | ||
| "when": "databricks.context.isActiveFileInActiveWorkspace && databricks.context.showRunAsWorkflow || databricks.context.isActiveFileInActiveWorkspace && resourceExtname == .ipynb" | ||
| "when": "!databricks.context.remoteMode && databricks.context.isActiveFileInActiveWorkspace && databricks.context.showRunAsWorkflow || !databricks.context.remoteMode && databricks.context.isActiveFileInActiveWorkspace && resourceExtname == .ipynb" |
There was a problem hiding this comment.
VS Code's when clause language evaluates && before ||, so this works correctly — but it's fragile and hard to read. Parentheses would make intent clearer:
"when": "!databricks.context.remoteMode && (databricks.context.isActiveFileInActiveWorkspace && databricks.context.showRunAsWorkflow || databricks.context.isActiveFileInActiveWorkspace && resourceExtname ==
.ipynb)"
| ); | ||
|
|
||
| customWhenContext.setActivated(true); | ||
| return undefined; |
There was a problem hiding this comment.
The remote-mode block doesn't log anything (e.g., "Activating in remote SSH mode"). This could make debugging harder if something goes wrong. The rest of the extension uses logging extensively.
| ); | ||
|
|
||
| customWhenContext.setActivated(true); | ||
| return undefined; |
There was a problem hiding this comment.
Minor style nit: The activate() function's return type likely expects the extension API or void. Returning undefined explicitly works but return; would be more idiomatic if the function signature allows it.
Replace the placeholder tree view with simply hiding the entire configuration view panel via a when-condition. This is simpler and avoids unnecessary UI clutter. Co-authored-by: Isaac
## Changes The extension changes are in a separate PR - databricks/databricks-vscode#1861 Here we set our extension id to the IDE settings And also set special env var that will tell the extension to initialize in a special "remote" mode, wher it only sets the active venv and does nothing else (for now) ## Why venv activation is one of the main friction points ## Tests <!-- How have you tested the changes? --> <!-- If your PR needs to be included in the release notes for next release, add a separate entry in NEXT_CHANGELOG.md as part of your PR. -->
|
If integration tests don't run automatically, an authorized user can run them manually by following the instructions below: Trigger: Inputs:
Checks will be approved automatically on success. |
Changes
https://docs.databricks.com/aws/en/dev-tools/ssh-tunnel
When running inside a Databricks Remote SSH session (DATABRICKS_REMOTE_ENV=1 and DATABRICKS_VIRTUAL_ENV set), the extension now activates in a minimal mode: it sets the Python virtual env path, registers a placeholder tree view, and disables all Databricks-specific commands/views/menus via the new
databricks.context.remoteModewhen-context.Tests
Manually + plus new unit tests