Repository navigation
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>
Co-authored-by: Isaac <no-reply@databricks.com>
Collaborator
Integration test reportCommit: d40a322
Top 6 slowest tests (at least 2 minutes):
|
rugpanov
force-pushed
the
uv-workspace-setup-local-2
branch
from
October 12, 2026 11:59
d40a322 to
5b12fd3
Compare
Collaborator
Integration test reportCommit: cd21b08
Top 6 slowest tests (at least 2 minutes):
|
This was referenced Oct 12, 2026
rugpanov
marked this pull request as ready for review
October 12, 2026 15:42
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
…e root Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
…mber Co-authored-by: Isaac <no-reply@databricks.com>
Co-authored-by: Isaac <no-reply@databricks.com>
uv prints the root in the on-disk letter case, while the shell keeps the case the user typed, so a name comparison treated a standalone project on a case-insensitive file system as a member of itself. Co-authored-by: Isaac <no-reply@databricks.com>
…root Removing a stale managed block from a member now keeps its [tool.uv] header when user keys follow the block. A workspace root that defines [tool.uv] with dotted keys fails the merge instead of getting a second [tool.uv] table. Co-authored-by: Isaac <no-reply@databricks.com>
- Warn when the root pins are replaced, also when the user wrote them. - Report diskMutated from both pyproject writes; name the workspace root in root write errors. - Fix the Windows activate hint for a relative venv path. - Say in the help that uv sync removes packages only other members need. - Rename SkipToolUv to ConstraintsAtWorkspaceRoot and set it with the other merge options; test WorkspaceRoot; tidy tests and acceptance scripts. Co-authored-by: Isaac <no-reply@databricks.com>
- Count the venv path levels from the symlink-resolved project folder, so a symlink that changes the folder depth reports the venv uv uses. - Reject a root that defines [tool.uv] with quoted or inline keys too. - Warn about replaced root pins only when the file had constraint pins, not when a comment names the key. - Remove unmarked constraint pins that an older run left in a member. - Run uv workspace dir through runUvOutput; label the root region in the dry-run plan; correct the greenfield comments; extend the help text. Co-authored-by: Isaac <no-reply@databricks.com>
The line-based merge matches only the plain [tool.uv] spelling, so a root that spells it differently could get a table or key defined twice. The merged root must now parse as TOML. An empty managed block no longer counts as pins to replace, and the member acceptance test re-runs in text mode. Co-authored-by: Isaac <no-reply@databricks.com>
…nk lines The dry-run plan now names the workspace root file only when the run would change it. Removing a header-less managed block from a member keeps the user's blank line before it, and an empty constraint-dependencies list no longer counts as pins to replace. Co-authored-by: Isaac <no-reply@databricks.com>
In this CLI, "workspace" usually means a Databricks workspace. The new fields are uvWorkspaceRoot, uvWorkspaceBackupPath, plan.wouldWriteUvWorkspace, and plan.wouldBackupUvWorkspace, and the text output says "uv workspace root". Co-authored-by: Isaac <no-reply@databricks.com>
…the names - An interrupt while uv workspace dir runs no longer falls back to the standalone behavior: with cached constraints, that run went on to rewrite the member pyproject.toml before it reported E_CANCELED. - Rename the warning to W_UV_WORKSPACE_CONSTRAINTS_REPLACED and the Go fields to match the uv-prefixed JSON names. Co-authored-by: Isaac <no-reply@databricks.com>
rugpanov
force-pushed
the
uv-workspace-setup-local-2
branch
from
October 12, 2026 16:13
3914917 to
cd21b08
Compare
This branch has not been deployed
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
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
databricks environments setup-localnow works in a member of a uv workspace (one shared venv for several bundles):uv workspace dir, uv 0.9.9 or later). It compares folders by identity, so symlinks and letter case do not change the result.<root>/.venv.venvPathstays relative to the project folder, for example../../.venv.[tool.uv]constraint block goes to the rootpyproject.toml, because uv reads constraints only from there.requires-pythonanddatabricks-connectstay in the member. A stale constraint block in the member is removed.[tool.uv]without a[tool.uv]header, and the merged root must parse as TOML.W_UV_WORKSPACE_CONSTRAINTS_REPLACED: the run replaced root pins that an earlier run or the user wrote. All members share these pins.omitemptyJSON fields:uvWorkspaceRoot,uvWorkspaceBackupPath,plan.wouldWriteUvWorkspace,plan.wouldBackupUvWorkspace(theuvprefix keeps them apart from a Databricks workspace). The output for other projects does not change.Why
In a member,
uv synccreates the venv at the workspace root, but the command validated<member>/.venvand failed. It also wrote the pins to the member file, where uv ignores them (databricks/databricks-vscode#2157).Tests
--no-constraints, and a read-only root.workspace dir.DATABRICKS_LOCALENV_TEST_PROVISION). It fails before this change and passes after it. It also checks thatuv.lockapplies the root pin.Reviewer notes
venvPathagainst the project folder, and restoreuvWorkspaceBackupPathafter a failure.Known limitations
pyproject.tomlis not detected as a member. If amembersglob matches it, the first run fails and a second run works. A follow-up fix is planned.uv syncstill reports conflicts with other members or the root asE_PROVISION_CONFLICT, after the root file changed.constraint-dependenciesthat a user wrote in the rootpyproject.toml. It emitsW_UV_WORKSPACE_CONSTRAINTS_REPLACEDand keeps a backup.uv syncis exact, so a run for one member removes packages that only other members need. All members must target compatible compute.venvPathis 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+/.venvis correct in all cases.venvPath, because Windows resolves..by text.This pull request and its description were written by Isaac.