fix(python-setup): show setup for a packaging-only pyproject.toml

[rugpanov]

Why

A freshly-initialised bundle project never surfaced the "Set up Python environment" entry.

The pyproject.toml that databricks bundle init default-python generates declares [project] and [build-system] but no [tool.uv], and ships no uv.lock. That fires the pyproject.pipOnly signal, attributes the project to pip, and the gate hides the entry because pip counts as a competing manager. The legacy pip checklist showed instead.

This inverts the intent. uv manages such a project natively — it needs neither a [tool.uv] section nor a lockfile — and these are precisely the projects the feature exists to set up. The design doc's argument that "our own example/bundle-init project already ships with uv, so the fully automated path matches what new users land on" only holds once someone has run uv lock. The skew was already documented as a telemetry measurement caveat; this is the same root cause surfacing as a product defect.

Measured on a real bundle init project, before and after:

managers: ["uv", "pip"]
signals:  ["uv.lock", "pyproject.pipOnly"]
gate: false   ← main
gate: true    ← this PR

Note the first line: adding a uv.lock is not a workaround. It correctly attributes uv, but pyproject.pipOnly still fires, so pip stays in managers and the gate still rejects the project even with uv as primary. Before this change the only way to surface the entry was to hand-add a literal [tool.uv] section.

What

Discount a pip attribution in the gate when it rests solely on the pyproject's shape. Pip is ignored when pyproject.pipOnly fired and no substantive pip signal did:

• requirements.txt
• constraints.txt
• interpreter.venv (an existing non-uv virtualenv)

Those three remain disqualifying — they are positive evidence that someone drives pip directly, and offering uv setup there would fight their tooling. Poetry and conda are never discounted.

Why in the gate, not the classifier

Loosening pyproject.pipOnly in packageManagerDetection.ts would have been the smaller diff, but that signal also feeds the package-manager telemetry dataset. Redefining it there would silently change what the metric counts and break comparability with data already collected — the classifier's job is to describe the project, and it is describing it accurately.

The gate is the only consumer whose behaviour should change, so PythonSetupManagerDetector now forwards signals alongside primary/managers for it to read. The manager list alone cannot express the distinction: a real pip workflow and a merely packaging-shaped pyproject.toml both read as "pip".

Tests

• yarn tsc --noEmit clean; yarn test:lint clean (eslint + prettier).
• yarn test:unit: 481 passing, 6 failing. The 6 are the pre-existing CliWrapper listProfiles failures, which also fail on unmodified main (they shell out to a real CLI binary absent from the worktree). 474 passed before this change, so all 7 new cases pass and nothing regressed.
• New coverage: shows for a shape-only pip attribution; still hides for each of the three substantive pip signals individually; shows for uv + shape-only pip; and poetry/conda alongside a shape-only pip still hide.
• Verified end to end against a real bundle-init project by running the actual signal collector and gate over it — not just unit fixtures — and separately in a dogfood VSIX build.

This pull request and its description were written by Isaac.

[rugpanov]

🤖 Integration tests ❌ 9 of 35 test jobs failed for c6f690b4 (26 passed).
View run

[misha-db]

Should this change be applied to greenfieldSignal() as well?

[rugpanov]

Good catch — done in f6b3cf9.

Extracted isUvSetupSuitable(detection) as the single source of truth and pointed both the gate and greenfieldSignal at it, so they can't drift. Knock-on: the deps seam became getDetection(), since the predicate needs managers + signals, not just primary (still one detection per click).

Note this flips isGreenfield from omitted to false for bundle-init projects, not to true — they do have a pyproject.toml. The win is that packageManager: "pip" + isGreenfield: undefined currently makes uv-suitable projects indistinguishable from real pip ones in the dataset.

494 tests passing (+7); exhaustive pass over all 3072 signal combinations confirms the gate and predicate agree everywhere.

[rugpanov]

🤖 Integration tests triggered for f6b3cf9e — ⏳ running.
View run

[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: 2086
• Commit SHA: da80a231be07b05b99a421e648a345f1032f0ed3

Checks will be approved automatically on success.