If dg dev cannot find the venv for a project inside a uv workspace, create a .env file in the project directory with DG_PROJECT_PYTHON_EXECUTABLE set to the shared venv's python binary (for example workspace_1/.venv/bin/python), using plain KEY [your value] or export KEY [your value] syntax. That is the supported escape hatch the maintainers point at while uv-workspace auto-detection is still unplanned. Do not symlink .venv: it does not work with Pixi or Conda style environments.

Context: GitHub issue dagster-io/dagster#31346 (closed, 14 comments): dg dev assumes each project has its own .venv next to dg.toml, so it fails in uv workspaces where several projects share one .venv at the workspace root. The venv path was not configurable. The workaround the reporter verified: set DG_PROJECT_PYTHON_EXECUTABLE in the project's .env file to point at the shared venv's python. A follow-up fix swapped dg's bespoke .env parser for python-dotenv, so export KEY [your value] quoted values, and trailing comments all work in that file.

## Matched source
Source: Published skill
Original query: "dg dev with uv workspaces: point DG_PROJECT_PYTHON_EXECUTABLE at the shared venv"
Key terms: executable, point, project, python, shared, venv, workspaces