sudo apt-get install -y --no-install-recommends \
        freetds-bin \
        krb5-user \
        ldap-utils \
        libffi6 \
        libsasl2-2 \
        libsasl2-modules \
        libssl1.1 \
        locales  \
        lsb-release \
        sasl2-bin \
        sqlite3 \
        unixodbc
You also need database client packages (Postgres or MySQL) if you want to use those databases.
Constraints files¶
Airflow installation might be sometimes tricky because Airflow is a bit of both a library and application.
Libraries usually keep their dependencies open and applications usually pin them, but we should do neither
and both at the same time. We decided to keep our dependencies as open as possible
(in setup.cfg and setup.py) so users can install different
version of libraries if needed. This means that from time to time plain pip install apache-airflow will
not work or will produce unusable Airflow installation.
In order to have repeatable installation, starting from Airflow 1.10.10 and updated in
Airflow 1.10.13 we also keep a set of “known-to-be-working” constraint files in the
constraints-main, constraints-2-0 orphan branches and then we create tag
for each released version e.g. constraints-2.1.2. This way, when we keep a tested and working set of dependencies.
Those “known-to-be-working” constraints are per major/minor Python version. You can use them as constraint
files when installing Airflow from PyPI. Note that you have to specify correct Airflow version
and Python versions in the URL.
You can create the URL to the file substituting the variables in the template below.
https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt
where:
AIRFLOW_VERSION - Airflow version (e.g. 2.1.2) or main, 2-0, for latest development version
PYTHON_VERSION Python version e.g. 3.8, 3.7
There is also a no-providers constraint file, which contains just constraints required to install Airflow core. This allows
to install and upgrade airflow separately and independently from providers.
You can create the URL to the file substituting the variables in the template below.
https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-no-providers-${PYTHON_VERSION}.txt
Installation script¶
In order to simplify the installation, we have prepared examples that will select
the constraints file compatible with your Python version.
Installing Airflow with extras and providers
If you need to install extra dependencies of airflow,
you can use the script below to make an installation a one-liner (the example below installs
postgres and google provider, as well as async extra.
AIRFLOW_VERSION=2.1.2
PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
pip install "apache-airflow[async,postgres,google]==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"
Note, that it will install the versions of providers that were available at the moment this version of Airflow
has been prepared. You need to follow next steps if you want to upgrade provider packages in case they were
released afterwards.
Upgrading Airflow with providers
You can also upgrade airflow together with extras (providers available at the time of the release of Airflow
being installed.
AIRFLOW_VERSION=2.1.2
PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt"
pip install --upgrade "apache-airflow[postgres,google]==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"
Installation and upgrading of Airflow providers separately
You can manually install all the providers you need. You can continue using the “providers” constraint files
but the ‘versioned’ airflow constraints installs only the versions of providers that were available in PyPI at
the time of preparing of the airflow version. However, usually you can use “main” version of the providers
to install latest version of providers. Usually the providers work with most versions of Airflow, if there
will be any incompatibilities, it will be captured as package dependencies.
PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
# For example: 3.6
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-main/constraints-${PYTHON_VERSION}.txt"
pip install "apache-airflow-providers-google" --constraint "${CONSTRAINT_URL}"
You can also upgrade the providers to latest versions (you need to use main version of constraints for that):
PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
# For example: 3.6
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-main/constraints-${PYTHON_VERSION}.txt"
pip install "apache-airflow-providers-google" --upgrade --constraint "${CONSTRAINT_URL}"
Installation and upgrade of Airflow core:
If you don’t want to install any extra providers, initially you can use the command set below.
AIRFLOW_VERSION=2.1.2
PYTHON_VERSION="$(python --version | cut -d " " -f 2 | cut -d "." -f 1-2)"
# For example: 3.6
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-no-providers-${PYTHON_VERSION}.txt"
# For example: https://raw.githubusercontent.com/apache/airflow/constraints-no-providers-2.1.2/constraints-3.6.txt
pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint "${CONSTRAINT_URL}"
Support for Python and Kubernetes versions¶
As of Airflow 2.0 we agreed to certain rules we follow for Python and Kubernetes support.
They are based on the official release schedule of Python and Kubernetes, nicely summarized in the
Python Developer’s Guide and
Kubernetes version skew policy.
We drop support for Python and Kubernetes versions when they reach EOL. We drop support for those
EOL versions in main right after EOL date, and it is effectively removed when we release the
first new MINOR (Or MAJOR if there is no new MINOR version) of Airflow
For example for Python 3.6 it means that we drop support in main right after 23.12.2021, and the first
MAJOR or MINOR version of Airflow released after will not have it.
The “oldest” supported version of Python/Kubernetes is the default one. “Default” is only meaningful
in terms of “smoke tests” in CI PRs which are run using this default version and default reference
image available in DockerHub. Currently apache/airflow:latest and apache/airflow:2.0.2 images
are both Python 3.6 images, however the first MINOR/MAJOR release of Airflow release after 23.12.2021 will
become Python 3.7 images.
We support a new version of Python/Kubernetes in main after they are officially released, as soon as we
make them work in our CI pipeline (which might not be immediate due to dependencies catching up with
new versions of Python mostly) we release a new images/support in Airflow based on the working CI setup.
Installing Airflow From Released Sources and packages¶
You can also install Airflow using the official sources and packages. Those sources and packages
released are the “official” sources of installation that you can use if you want to verify the
origin of the packages and want to verify checksums and signatures of the packages.
The packages are available at the
Official Apache Software Foundations Downloads page
The 2.1.2 downloads are available at:
Apache Airflow 2.1.2 sdist package (asc, sha512)
Apache Airflow 2.1.2 wheel package (asc, sha512)
Apache Airflow 2.1.2 sources (asc, sha512)
Set up a database¶
Airflow requires a database. If you’re just experimenting and learning Airflow, you can stick with the
default SQLite option. If you don’t want to use SQLite, then take a look at
Set up a Database Backend to setup a different database.
Troubleshooting¶
This section describes how to troubleshoot installation issues.
Airflow command is not recognized¶
If the airflow command is not getting recognized (can happen on Windows when using WSL), then
ensure that ~/.local/bin is in your PATH environment variable, and add it in if necessary:
PATH=$PATH:~/.local/bin
You can also start airflow with python -m airflow
Symbol not found: _Py_GetArgcArgv¶
If you see Symbol not found: _Py_GetArgcArgv while starting or importing Airflow, this may mean that you are using an incompatible version of Python.
For a homebrew installed version of Python, this is generally caused by using Python in /usr/local/opt/bin rather than the Frameworks installation (e.g. for python 3.7: /usr/local/opt/python@3.7/Frameworks/Python.framework/Versions/3.7).
The crux of the issue is that a library Airflow depends on, setproctitle, uses a non-public Python API
which is not available from the standard installation /usr/local/opt/ (which symlinks to a path under /usr/local/Cellar).
An easy fix is just to ensure you use a version of Python that has a dylib of the Python library available. For example:
# Note: these instructions are for python3.7 but can be loosely modified for other versions
brew install python@3.7
virtualenv -p /usr/local/opt/python@3.7/Frameworks/Python.framework/Versions/3.7/bin/python3 .toy-venv
source .toy-venv/bin/activate
pip install apache-airflow
python
>>> import setproctitle
# Success!
Alternatively, you can download and install Python directly from the Python website.
Installation script
Support for Python and Kubernetes versions
Installing Airflow From Released Sources and packages
Set up a database
Troubleshooting

Airflow command is not recognized
Symbol not found: _Py_GetArgcArgv
            Apache Airflow, Apache, Airflow, the Airflow logo, and the Apache feather logo are either registered trademarks or trademarks of The Apache Software Foundation.
            All other products or name brands are trademarks of their respective holders, including The Apache Software Foundation.