[VPEX] localenv: rename compute-target vocabulary target → compute - #6100
Open
rugpanov wants to merge 1 commit into
Open
[VPEX] localenv: rename compute-target vocabulary target → compute#6100rugpanov wants to merge 1 commit into
target → compute#6100rugpanov wants to merge 1 commit into
Conversation
Contributor
Approval status: pending
|
The setup-local --output json result named the resolved compute object "target". Rename it to "compute" so the wire format, the Go model, and the resolver vocabulary all match the invocation-side field name the VS Code extension already adopted (SetupLocalInvocation.target → compute, databricks-vscode#2039). The extension parses the payload with a bare structural cast, so the JSON key must match the model field. The rename is carried through the whole compute-selection layer, not just the wire key, so the field/type/function names no longer drift from the "compute" concept (the extension makes the same move: PythonSetupTargetInfo → PythonSetupComputeInfo): - Result.Target field + json tag → Compute / "compute" - TargetInfo type → ComputeInfo - ResolveTarget function → ResolveCompute - TargetFlags / ValidateTargetFlags → ComputeFlags / ValidateComputeFlags - libs/localenv/target.go(+_test) → compute.go(+_test) Deliberately NOT renamed: - BundleTarget — "target" is first-class bundle vocabulary (databricks.yml targets:, --target), so it is correctly named at that boundary. - ErrNoTarget / E_NO_TARGET — the Go const mirrors the stable wire error-code string; renaming would desync it from the error-code contract. - ComputeClient — already "compute". SchemaVersion stays 1: the command is still hidden with no shipped JSON consumer, so there is no old payload in the wild to distinguish and no compatibility window is needed. It will bump once the command is unveiled and the contract has real consumers. Part of DECO-27794 (CLI side). The extension-side model rename is tracked separately in databricks-vscode. Co-authored-by: Isaac
rugpanov
force-pushed
the
dbconnect/rename-target-compute
branch
from
July 29, 2026 17:11
074c0ce to
42f9da2
Compare
target → computetarget → compute
Collaborator
Integration test reportCommit: 42f9da2
11 interesting tests: 4 SKIP, 3 FAIL, 3 RECOVERED, 1 KNOWN
Top 1 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
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.
What
Rename the compute-selection vocabulary from
targettocomputeacross thesetup-locallayer, so the--output jsonresult key, the Go model, and theresolver names all match the invocation-side field the VS Code extension already
adopted (
SetupLocalInvocation.target→compute, databricks-vscode#2039).Why carry it beyond the wire key
The extension parses the CLI result with a bare structural cast, so the JSON key
must match the model field. Renaming only the tag would leave
Result.Compute *TargetInfojson:"compute"— three-way naming drift for one concept. Theextension makes the same full move (
PythonSetupTargetInfo→PythonSetupComputeInfo), so this aligns the whole vocabulary.Renamed
Result.Targetfield + json tag →Compute/"compute"TargetInfotype →ComputeInfoResolveTarget→ResolveComputeTargetFlags/ValidateTargetFlags→ComputeFlags/ValidateComputeFlagslibs/localenv/target.go(+_test) →compute.go(+_test)Deliberately NOT renamed
BundleTarget— "target" is first-class bundle vocabulary (databricks.ymltargets:,--target), correctly named at that boundary.ErrNoTarget/E_NO_TARGET— the Go const mirrors the stable wireerror-code string; renaming would desync it from the error-code contract.
ComputeClient— already "compute".schemaVersion stays 1
Not bumped: the command is still
Hiddenwith no shipped JSON consumer, sothere's no old payload in the wild to distinguish and no compatibility window to
maintain. It will bump once the command is unveiled and the contract has real
consumers. (Confirmed with the ticket owner; drops the ticket's step-3
"tolerate both keys" work for the CLI side.)
Test
Build, unit (
libs/localenv,cmd/environments), acceptance(
serverless-json/constraints-only/json-errorregenerated), lint (0),deadcode — all pass.
Part of DECO-27794 (CLI side). The extension-side model rename
(
PythonSetupResult.target→compute,PythonSetupTargetInfo→PythonSetupComputeInfo, errorMessages/fixtures/tests) is tracked separately indatabricks-vscode.
This pull request and its description were written by Isaac.