Use vscode:// deep links for session URLs in VS Code - #194
Conversation
When running inside VS Code, session detail links now point to the googlecloudtools.datacloud extension's session view instead of the Cloud Console, for the session-creation message, existing-session reattach message, and the notebook repr's session link.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a helper function _build_session_details_url to dynamically generate VS Code-specific session URLs when running in a VS Code environment, updating several display and print locations to use this helper. Unit tests are also added to verify this behavior. The feedback suggests updating the type hints of the helper's parameters to Optional[str] to prevent static analysis errors, and registering cleanups for mock.patch.dict calls in the unit tests to avoid test environment pollution.
Address review feedback: the url was being assembled partly in _repr_html_ and partly inline in the <a href>; build it in full where the other session-related urls are constructed.
region and project_id are always passed self._region/self._project_id, which are Optional[str] until a session connects.
| ) | ||
|
|
||
| _VSCODE_SESSION_URI_BASE = ( | ||
| "vscode://googlecloudtools.datacloud/dataproc/sessions" |
There was a problem hiding this comment.
This only works if they have DAK installed, it will fail confusingly otherwise.
There was a problem hiding this comment.
Good catch — fixed in 48d68a3. Added environment.is_vscode_extension_installed(), which shells out to code --list-extensions (cached, fails closed on any error/timeout/missing CLI), and _build_session_details_url now only uses the vscode:// link when the extension is actually installed, falling back to the Cloud Console url otherwise.
There was a problem hiding this comment.
code --list-extensions only works for VS Code, not for its various forks (agy-ide, etc.). Sorry for not having more helpful suggestions, but I'm worried there is no reliable way to tell what IDE it's running in. I don't even know if VSCODE_PID is reliable...
There was a problem hiding this comment.
yeah, I'm struggling to find another solution too. let me poke around a bit more.
There was a problem hiding this comment.
Follow-up on this: code may not be on PATH even when VS Code and the extension are installed (e.g. macOS before running "Shell Command: Install 'code' command in PATH", or a remote/SSH session). Added a fallback in eb35825 that scans the on-disk extensions directories (~/.vscode/extensions, ~/.vscode-server/extensions, etc.) directly when the CLI check doesn't find it.
There was a problem hiding this comment.
One more follow-up: on a vscode-server (Remote-SSH) backend, code --list-extensions goes through a client-forwarding shim whose behavior for that flag isn't reliable, so in 6bb6ffa I skip the CLI check entirely when running on a detected remote backend (~/.vscode-server present) and trust only the ~/.vscode-server/extensions disk scan there.
There was a problem hiding this comment.
Simplified this in 4eed13d: dropped the extension-detection logic entirely (it kept growing more edge cases — PATH, Remote-SSH shim reliability, forks, code-server). Now we just always show both the Cloud Console link and the vscode:// link when running inside VS Code, and let the extension's own URI handler be the failure point if it's not installed.
The vscode:// deep link only resolves if googlecloudtools.datacloud is installed; otherwise VS Code shows a generic, confusing error. Check via `code --list-extensions` and fall back to the Cloud Console url when it's not present or the check can't run.
48d68a3 to
728f341
Compare
code may not be on PATH even when VS Code and the extension are installed (e.g. macOS before running "Shell Command: Install 'code' command in PATH", or a remote/SSH session using .vscode-server). Scan the on-disk extensions directories as a fallback so the vscode:// link still shows up in those cases.
On a remote backend, code runs through a client-forwarding shim whose --list-extensions behavior isn't reliable, so only the on-disk ~/.vscode-server/extensions scan is trusted there.
Reliably detecting whether the Data Analytics Kit extension is installed proved impractical across local VS Code, Remote-SSH, and forks. Simplify by always showing both the Cloud Console link and the vscode:// deep link whenever running inside VS Code, and let the extension's own URI handler be the point of failure if it's missing.
Rename the link labels to "Managed Spark Session (Cloud Console)" and "Managed Spark Session (Data Agent Kit)" so it's clear which link goes where.
2 participants
Summary
VSCODE_PIDset), session detail messages/links now show both a Cloud Console link and avscode://googlecloudtools.datacloud/dataproc/sessions/<id>?project=<project>&location=<region>deep link, instead of trying to detect which one to show.code --list-extensionsisn't always on PATH, its behavior is unreliable when forwarded through the Remote-SSH shim, extensions directories differ across forks/code-server, and even a correct disk scan can't confirm client-side installation state from a remote backend. Rather than chase that, we just always show both links and let the extension's own URI handler be the point of failure if it's missing..../dataproc/interactive/{region}/{session_id}?project={project_id}URL shape: the new-session-created message, the reattach-to-existing-session message, and the notebook_repr_html_(which now shows both session links plus "Spark UI").Test plan
_display_session_link_on_creation,_get_exiting_active_session, and_repr_html_asserting both links are present when in VS Code, and a test confirming no vscode link when not.uv run pyink --checkclean on all changed files.uv run pytest tests/unit/— 165 passed, 1 pre-existing unrelated failure (test_create_session_without_application_default_credentials, fails identically onmain).