Update: dg is agnostic to package manager by default and can be incrementally adopted in existing projects

[schrockn]

We pushed out 1.10.11 last week. It has updates as you would expect, but the news that I wanted to explicitly raise is that we have altered our defaults and framing when it comes to virtual environment management:

Package-Manager-Neutral (uv or pip) Docs:

We have changed our docs to have both uv and pip instructions for all tutorials and examples. (Since we support pip it should be fairly straightforward to adapt these instructions to other package manager) Nothing in dg is deeply tied to uv, but our original post, docs, and positioning did not frame this appropriately nor did it default to the most intuitive behavior for experienced Python users. To be clear: You can use dg in any project (with some modest incremental changes) and on top of any package manager. You do not need to radically restructure anything or change your existing toolchain.

Changing Default Behavior of Virtual Environments:

We have defaulted to a more traditional usage of virtual environments: using the currently active virtual environment (typically activated via running source path/to/your/venv/bin/activate) rather than default to a uv-managed approach which manages ephemeral environments on your behalf (by launching all subprocesses with uv run).

For those who already manage their own virtual environments, the uv-managed approach to virtual environments was confusing and caused difficult-to-debug environment issues, as the system did too much “magic” when transparency is what was desired.

The new default scaffolding flow for uv is:

uv tool install dagster-dg
dg init my_project (prompts you to run uv sync)
cd my_project
source .venv/bin/activate

For pip (and other package managers) you just install dagster-dg in your project environment (as you would with other python packages that install a CLI in your path)( and run dg init .

Opt-in available for environments fully managed by uv

We are still excited about the potential of virtual environments fully managed by uv and uv run, and think it will be the ideal workflow for users who do not understand virtual environments and do not have existing habits and workflows to manage them. We still support this option at init time through the --python-environment uv_managed option on init and think it will be the right solution for less-technical stakeholders who want Python to “just work” with thinking about environments at all.

Thanks all for bearing with us and thank you for providing the feedback which led to this change!