denver

Development Environments as code — reproducible, flexible, simple and fast.

Development Environment Launcher — declares dev environments in a denver.toml: reproducible and layerable to fit your project's needs.

What problem does this solve?

Every project needs some setup before it builds — a fresh clone, a submodule init, a venv, a toolchain install. How much varies wildly, but the pattern is the same: you run a pile of one-off steps to get a working build the first time, then forget which ones to rerun after switching branches. The result is broken builds and "works on my machine" debugging that has nothing to do with your actual code.

denver fixes this by making setup declarative. You describe the steps a project needs in a denver.toml, and denver runs them the same way every time — for you, for teammates, and in CI. It only runs the stages your project actually needs, so it stays fast, and it has no opinion about which tools you use: denver just runs what you declare.

Read the full walkthrough → — the problem built up one step at a time, from that first script to import:-based inheritance across a whole fleet of projects.

Documentation

Built documentation is available on GitHub Pages.

Install

pip install denver-tool   # or: uv tool install denver-tool

Alternatively, call src/denver.py directly, no install needed:

src/denver.py --version

or set up an alias so it behaves like an installed command:

alias denver="$PWD/src/denver.py"
denver --version

For more alternatives how to use or install denver see Install denver →.

Tab Completion

Tab completion works in bash, zsh, and fish.

bash/zsh:

eval "$(denver complete)"

fish:

denver complete | source

See Shell completion → for making it permanent.

Try it

denver run examples/howto-env -- pytest examples/howto-env/tests

A minute or two later (much less on repeat runs), that one command has built a container, a Python venv, a hand-installed tool, and a conan-installed toolchain, applied a team convention, and run tests proving all five actually work — from a single denver.toml, identically on your machine or your colleague's.

Denver in 5 minutes → walks through each stage and explains it, including all the flags and config options you'll actually use. For every flag, see CLI arguments → or run denver --help.

Known limitations

denver has zero runtime dependencies. Its config format is TOML (denver.toml), parsed with the standard library's tomllib — hence the >=3.11 floor. Nothing extra to install, on the host or inside a docker-wrapped image: a Dockerfile only needs python3 itself, since denver re-invoked inside the container needs nothing beyond the interpreter.

Note: stuck on Python < 3.11? Grab the prebuilt executable from a release, or build one yourself with uv run poe pyinstaller, and use that binary instead — see Prebuilt Binary. Alternatively run with uv run src/denver.py, e.g by setting alias denver="uv run $PWD/src/denver.py".

Contributing

Bug reports, feature requests and pull requests are welcome — see doc/contributing/development.md for the workflow (uv run poe all runs lint, format, mypy and the test suite; denver keeps 100% coverage).

License

Apache License 2.0 — see LICENSE.