Repository navigation
localenv: add venv-folder and per-file pyproject seams to setup-local - #7017
Merged
Merged
Conversation
Co-authored-by: Isaac <no-reply@databricks.com>
…elpers Co-authored-by: Isaac <no-reply@databricks.com>
…ath at preflight Co-authored-by: Isaac <no-reply@databricks.com>
Collaborator
Integration test reportCommit: 3bc7249
Top 6 slowest tests (at least 2 minutes):
|
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
misha-db
approved these changes
Oct 13, 2026
yuri-rod
pushed a commit
to yuri-rod/cli
that referenced
this pull request
Oct 13, 2026
…7018) **Stack** (merge in this order): 1. databricks#7017 localenv: add venv-folder and per-file pyproject seams to setup-local ([see diff](databricks/cli@main...uv-workspace-setup-local)) 2. databricks#7018 Support uv workspace members in environments setup-local ([see diff](databricks/cli@uv-workspace-setup-local...uv-workspace-setup-local-2)) **<- this PR** 3. databricks#7026 Honor UV_PROJECT_ENVIRONMENT in environments setup-local ([see diff](databricks/cli@uv-workspace-setup-local-2...uv-workspace-setup-local-3)) ## Changes `databricks environments setup-local` now works in a member of a uv workspace (one shared venv for several bundles): - The command asks uv for the workspace root (`uv workspace dir`, uv 0.9.9 or later). It compares folders by identity, so symlinks and letter case do not change the result. - For a member, the venv is `<root>/.venv`. `venvPath` stays relative to the project folder, for example `../../.venv`. - The `[tool.uv]` constraint block goes to the root `pyproject.toml`, because uv reads constraints only from there. `requires-python` and `databricks-connect` stay in the member. A stale constraint block in the member is removed. - The command does not write a root file that uv cannot read. It rejects a root that defines `[tool.uv]` without a `[tool.uv]` header, and the merged root must parse as TOML. - New warning `W_UV_WORKSPACE_CONSTRAINTS_REPLACED`: the run replaced root pins that an earlier run or the user wrote. All members share these pins. - New `omitempty` JSON fields: `uvWorkspaceRoot`, `uvWorkspaceBackupPath`, `plan.wouldWriteUvWorkspace`, `plan.wouldBackupUvWorkspace` (the `uv` prefix keeps them apart from a Databricks workspace). The output for other projects does not change. - The text summary shows the workspace root. The help text explains the shared venv. - An interrupt during discovery stops the run at preflight, before any file is written. ## Why In a member, `uv sync` creates the venv at the workspace root, but the command validated `<member>/.venv` and failed. It also wrote the pins to the member file, where uv ignores them (databricks/databricks-vscode#2157). ## Tests - Unit tests: discovery (member, standalone, greenfield, uv failure, symlinks, letter case), the root merge and its guards, an idempotent re-run, `--no-constraints`, and a read-only root. - Acceptance tests with a fake uv: a dry run in a member, a real run and a text-mode re-run in a member, and uv without `workspace dir`. - Integration test with real uv and a two-member workspace (gated by `DATABRICKS_LOCALENV_TEST_PROVISION`). It fails before this change and passes after it. It also checks that `uv.lock` applies the root pin. ## Reviewer notes - The VS Code extension needs a follow-up: resolve `venvPath` against the project folder, and restore `uvWorkspaceBackupPath` after a failure. ## Known limitations - With uv older than 0.9.9, discovery fails and the command keeps the standalone behavior. A member then fails as before. - A new folder with no `pyproject.toml` is not detected as a member. If a `members` glob matches it, the first run fails and a second run works. A follow-up fix is planned. - The pre-sync conflict check reads only the current member. `uv sync` still reports conflicts with other members or the root as `E_PROVISION_CONFLICT`, after the root file changed. - The command replaces `constraint-dependencies` that a user wrote in the root `pyproject.toml`. It emits `W_UV_WORKSPACE_CONSTRAINTS_REPLACED` and keeps a backup. - `uv sync` is exact, so a run for one member removes packages that only other members need. All members must target compatible compute. - `venvPath` is counted from the symlink-resolved project folder. If a symlink between the root and the member changes the folder depth, a consumer that joins paths by text gets a wrong folder. `uvWorkspaceRoot` + `/.venv` is correct in all cases. - On Windows, a member reached through a junction can get a wrong relative `venvPath`, because Windows resolves `..` by text. This pull request and its description were written by Isaac. --------- Co-authored-by: Isaac <no-reply@databricks.com>
Collaborator
Integration test reportCommit: 5e8d8f9
18 interesting tests: 10 flaky, 8 FAIL
Top 50 slowest tests (at least 2 minutes):
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stack (merge in this order):
Changes
This PR is a refactor in
libs/localenv. It does not change behavior. It adds two seams that #7018 uses for uv workspace members:PostProvisionandValidatetake the project folder and the venv folder. uv and the validate probe still run in the project folder. Preflight sets the venv folder; for every project it is still.venv.pyproject.tomlbackup, write, and dry-run diff are per-file helpers (writePyproject,pyprojectDiff, and backup helpers that take a folder). This lets Support uv workspace members in environments setup-local #7018 write a second file, the workspace rootpyproject.toml.Why
In a uv workspace member,
uv syncputs the venv at the workspace root, and uv reads the constraint pins only from the rootpyproject.toml(databricks/databricks-vscode#2157). The pipeline used one fixed venv path and onepyproject.toml. This PR makes both locations parameters, so #7018 can change them for a member without a mixed refactor-and-feature diff.Tests
Known limitations
This pull request and its description were written by Isaac.