Table of Contents generated with DocToc

• Apache Airflow Breeze
• Setting up development env for Breeze
• Integration tests

Apache Airflow Breeze

The project is part of Apache Airflow - it's a development environment that is used by Airflow developers to effortlessly setup and maintain consistent development environment for Airflow Development.

This package should never be installed in “production” mode. The breeze entrypoint will actually fail if you do so. It is supposed to be run directly against the Airflow sources you have checked out, in editable/development mode.

The recommended way to make breeze available is to install a small shim script at ~/.local/bin/breeze that runs breeze from the dev/breeze folder of the current git worktree via uvx. This avoids a single global install and means each git worktree (including ephemeral worktrees used by coding agents) gets its own breeze, tied to that worktree's sources. Because the shim is a real file on PATH, subprocesses (pre-commit hooks, CI scripts, dev tools) see it just like a uv tool-installed binary. See ADR 0017 for the rationale.

The scripts/tools/setup_breeze script installs the shim for you. If you previously installed breeze globally via uv tool install -e ./dev/breeze or pipx install -e ./dev/breeze, remove that install first — both write to ~/.local/bin/breeze and would conflict:

uv tool uninstall apache-airflow-breeze   # or: pipx uninstall apache-airflow-breeze

To install the shim manually, write this file to ~/.local/bin/breeze and chmod +x it:

#!/usr/bin/env bash
# Apache Airflow breeze shim — managed by scripts/tools/setup_breeze (ADR 0017).
set -e
repo_root=$(git rev-parse --show-toplevel 2>/dev/null) || {
    echo "breeze: not inside a git repository — cd into an Airflow worktree first" >&2
    exit 1
}
if [ ! -d "${repo_root}/dev/breeze" ]; then
    echo "breeze: ${repo_root} is not an Airflow worktree (no dev/breeze)" >&2
    exit 1
fi
exec env AIRFLOW_ROOT_PATH="${repo_root}" SKIP_BREEZE_SELF_UPGRADE_CHECK=1 \
    uvx --from "${repo_root}/dev/breeze" --quiet breeze "$@"

Then breeze invoked from any Airflow checkout uses that checkout's source. The first call in a fresh worktree pays a one-time uvx resolve/install; subsequent calls hit the cache.

The legacy global-install path (uv tool install -e ./dev/breeze --force or pipx install -e ./dev/breeze --force) still works for users who explicitly want a single shared install, but it is no longer the recommended approach.

You can read more about Breeze in the documentation

This README file contains automatically generated hash of the pyproject.toml files that were available when the package was installed. Since this file becomes part of the installed package, it helps to detect automatically if any of the files have changed. If they did, the user will be warned to upgrade their installations.

Setting up development env for Breeze

[!NOTE] This section is for developers of Breeze. If you are a user of Breeze, you do not need to read this section.

Breeze is actively developed by Airflow maintainers and contributors, Airflow is an active project and we are in the process of developing Airflow 3, so breeze requires a lot of adjustments to keep up the dev environment in sync with Airflow 3 development - this is also why it is part of the same repository as Airflow - because it needs to be closely synchronized with Airflow development.

As of November 2024 Airflow switchd to using uv as the recommended development environment for Airflow and for Breeze. So the instructions below are for setting up the development environment for Breeze using uv.

However we are using only standard python packaging tools, so you can still use pip or pipenv or other build frontends to install Breeze, but we recommend using uv as it is the most convenient way to install, manage python packages and virtual environments.

Unlike in Airflow, where we manage our own constraints, we use uv to manage requirements for Breeze and we use uv to lock the dependencies. This way we can ensure that the dependencies are always up-to-date and that the development environment is always consistent for different people. This is why Breeze‘s uv.lock is committed to the repository and is used to install the dependencies by default by Breeze. Here’s how to install breeze development environment with uv:

1. Install uv - see uv documentation

[!IMPORTANT]

1. The version of uv should be at least as defined in pyproject.toml under [tool.uv] section, otherwise some breeze commands might malfunction (but you will get error from uv about it).
2. All the commands below should be executed while you are in dev/breeze directory of the Airflow repository.

2. Create a new virtual environment for Breeze development (this step can be skipped, uv sync will create venv as needed when running uv sync)

uv venv

3. Synchronize Breeze dependencies with uv to the latest dependencies stored in uv.lock file:

uv sync

After syncing, the .venv directory in breeze folder will contain the virtual environment with all the dependencies installed - you can use that environment to develop Breeze - for example with your favourite IDE or text editor, you can also use uv run to run the scripts in the virtual environment.

For example to run all tests in the virtual environment you can use:

uv run pytest

4. Add/remove dependencies with uv:

uv add <package>
uv remove <package>

5. Update and lock the dependencies (after adding them or periodically to keep them up-to-date):

uv lock

Note that when you update dependencies/lock them you should commit the changes in pyproject.toml and uv.lock.

Integration tests

The integration tests for Breeze are located in dev/breeze/integration_tests directory. They are skipped by default, but you can run them with integration_tests marker

uv run pytest -m integration_tests

In CI environment (when CI environment variable is set) some of the tests are skipped and some of them are simulated so that no actual SVN commands are needed.

See uv documentation for more details on using uv.