[elainewang-db]

Summary

When a virtualenv is active, agentbricks dev installs the agent app's dependencies into that venv instead of the project's own .venv. The app's dependencies include older versions of packages, so this can silently downgrade whatever is installed there.

Cause: on a first run, agentbricks dev calls databricks apps run-local --prepare-environment.

1. That command creates the project's .venv.
2. It then installs the app's dependencies with uv pip.
3. uv pip installs into the active venv ($VIRTUAL_ENV) whenever one is set, and only falls back to the project's .venv otherwise.

The run-local log shows it:

Creating virtual environment at: .venv
Using Python 3.12.11 environment at: /…/some-other/.venv
 - databricks-sdk==0.142.0
 + databricks-sdk==0.33.0

run-local has no option to choose the target venv.

Fix: agentbricks dev now runs run-local with VIRTUAL_ENV removed from its environment, so dependencies go into the project's .venv. To make that possible, the shared _databricks helper gains an optional env argument. Its other callers don't pass it and are unchanged.

How we found it: the E2E suite in #706 runs under uv run pytest, which sets VIRTUAL_ENV to the test environment. Each agentbricks dev start downgraded the test environment's own packages mid-run, and the CLI under test then failed on import.

The underlying behavior is in databricks apps run-local, which should install into the venv it just created. That's worth raising with the Databricks CLI / Apps team separately.

Testing

• New unit test test_dev_hides_active_venv_from_run_local: with VIRTUAL_ENV set, run-local is called without it, and the rest of the environment is passed through.
• pytest tests/unit_tests passes: 1536 passed, 81 skipped.
• ruff check and ruff format --check are clean.
• ty check reports the same 38 diagnostics as main.

This pull request and its description were written by Isaac.

[jamesbxwu]

can you resolve merge conflict since my refactor changes have now landed?