[rugpanov]

Stack (merge in this order):

1. fix(python-setup): select the shared uv workspace venv for a workspace member #2253 fix(python-setup): select the shared uv workspace venv for a workspace member (see diff) <- this PR
2. fix(python-setup): recover a uv workspace member from a constraint conflict #2254 fix(python-setup): recover a uv workspace member from a constraint conflict (see diff)

Changes

In a monorepo with one uv workspace and one bundle per member, the Python environment setup selects the wrong interpreter (#2157). The Databricks CLI now supports uv workspace members in databricks environments setup-local (databricks/cli#7018, databricks/cli#7026). For a member, the CLI provisions one shared venv at the workspace root. It reports venvPath relative to the member folder, for example ../../.venv, and it adds uvWorkspaceRoot and uvWorkspaceBackupPath.

• The extension resolves venvPath to an absolute folder. It uses this folder to select the interpreter and to read the venv name from pyvenv.cfg.
  • A value that climbs (../../.venv) counts from the symlink-resolved project folder on Unix, as the CLI does.
  • .venv stays under the project folder as opened.
  • An absolute value (from an absolute UV_PROJECT_ENVIRONMENT) stays as it is.
• Before this change, the extension gave the Python extension a relative interpreter path. It also read pyvenv.cfg relative to the working folder of the extension host, so the venv name did not show in the summary. These fixes also apply to a standalone project.
• The result parser reads uvWorkspaceRoot and uvWorkspaceBackupPath.
• For a member, the success summary names the shared venv and the root pyproject.toml. The venv folder uses Windows separators on Windows.
• The warning histogram counts W_UV_WORKSPACE_CONSTRAINTS_REPLACED.

Tests

• New unit tests cover the venv folder for a member, a symlinked project folder, .venv under the opened folder, an absolute venvPath, the venv name, the result fields, the summary text on Linux and Windows, and the warning count.
• Full unit suite: 1401 passing, 0 failing. yarn run test:lint reports 0 errors.

Known limitations

• The fix for [BUG] uv Python setup assumes a per-bundle .venv — breaks a monorepo with one shared uv environment across multiple DABs #2157 needs a bundled CLI that contains Support uv workspace members in environments setup-local cli#7018. With the current CLI (1.20.0), venvPath is always .venv, and this PR changes only the two standalone fixes above.
• On Windows, the extension does not resolve a directory symlink in the project folder. The CLI resolves it for a member, so a member opened through such a symlink gets a wrong venv folder.

This pull request and its description were written by Isaac.

[rugpanov]

🤖 Integration tests running for 2374c915 — ⏳.
View run

[rugpanov]

🤖 Integration tests running for 5ecb3068 — ⏳.
View run

[rugpanov]

🤖 Integration tests ❌ failed for 9752a1c4.
View run

[rugpanov]

🤖 Integration tests ✅ passed for a1c4bd1c.
View run

[rugpanov]

🤖 Integration tests ✅ passed for e169b071.
View run

[misha-db]

A review turned up three low-severity items — all nice-to-haves, none blocking. Noting them here in case they're worth a follow-up.

1. Constraint-conflict recovery doesn't restore the workspace-root pyproject.toml

src/python-setup/controllers/PythonSetupEnvironmentSetup.ts (~L565)

For a uv workspace member, the conflicting managed pins live in the root pyproject.toml (the new uvWorkspaceBackupPath), but the Full-preset recovery only restores result.backupPath over cwd/pyproject.toml. On E_PROVISION_CONFLICT, "Retry DB Connect setup" rolls back only the member file; the root's conflicting pins stay on disk, so the --no-constraints retry can still resolve against them and the conflict may recur. uvWorkspaceBackupPath is wired up for display but not for recovery, and restoreProjectFile's lexical containment guard would reject the root backup anyway (it sits above cwd).

2. Success notification echoes a raw relative venvPath that diverges under symlinks

src/python-setup/utils/setupSummary.ts (~L131)

The toast/log print the CLI's raw relative venvPath (e.g. ../../.venv) interpreted from the opened folder, while adoption resolves a climbing path from the symlink-resolved real folder. If the member is opened via a symlink, adoption targets the correct venv but the displayed interpreter path (../../.venv/bin/python) resolves elsewhere from the opened folder — purely a cosmetic/display divergence.

3. A realpath failure gets labeled as an "adopt"-phase extension bug

src/python-setup/controllers/PythonSetupEnvironmentSetup.ts (~L618)

resolveVenvDir (which does the realpath call for climbing paths) sits inside the adopt try-catch. If the open folder is renamed/deleted during the multi-second CLI run, realpath(cwd) rejects with ENOENT and the catch labels failurePhase: 'adopt', surfacing a "Report this problem" action — mis-attributing an environmental/filesystem error to an extension defect, even though adoptInterpreter never ran.

[rugpanov]

Thanks for the review!

1. Root pyproject.toml restore: fix(python-setup): recover a uv workspace member from a constraint conflict #2254 fixes this. The retry checks and restores both backups, the member and the workspace root.
2. Raw relative venvPath in the toast: only the displayed text is different, so I will fix it in a follow-up.
3. realpath failure labeled as an extension bug: fixed in d377b62. A missing project folder now shows a plain error without "Report this problem" and records reportOffered: false.

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/vscode

Inputs:

• PR number: 2253
• Commit SHA: d377b620b44a9ef56d91d1de89ad1725a6fc0d5c

Checks will be approved automatically on success.

[rugpanov]

🤖 Integration tests ❌ failed for d377b620.
View run