@@ -28,11 +28,8 @@ That's why we recommend using local virtualenv for development and testing.
28
28
29
29
**The outline for this document in GitHub is available at top-right corner button (with 3-dots and 3 lines). **
30
30
31
- Installation in local virtualenv
32
- --------------------------------
33
-
34
31
Required Software Packages
35
- ..........................
32
+ --------------------------
36
33
37
34
Use system-level package managers like yum, apt-get for Linux, or
38
35
Homebrew for macOS to install required software packages:
@@ -42,8 +39,12 @@ Homebrew for macOS to install required software packages:
42
39
* libxml
43
40
* helm (only for helm chart tests)
44
41
45
- Refer to the `Dockerfile.ci <../Dockerfile.ci >`__ for a comprehensive list
46
- of required packages.
42
+ There are also sometimes other system level packages needed to install python packages - especially
43
+ those that are coming from providers. For example you might need to install ``pkgconf `` to be able to
44
+ install ``mysqlclient `` package for ``mysql `` provider . Or you might need to install ``graphviz `` to be able to install
45
+ ``devel `` extra bundle.
46
+
47
+ Please refer to the `Dockerfile.ci <../Dockerfile.ci >`__ for a comprehensive list of required packages.
47
48
48
49
.. note ::
49
50
@@ -61,26 +62,114 @@ of required packages.
61
62
released wheel packages.
62
63
63
64
64
- Installing Airflow
65
- ..................
65
+ Creating and maintaining local virtualenv with uv
66
+ -------------------------------------------------
67
+
68
+ As of November 2024 we are recommending to use ``uv `` for local virtualenv management for Airflow development.
69
+ The ``uv `` utility is a build frontend tool that is designed to manage python, virtualenvs and workspaces for development
70
+ and testing of Python projects. It is a modern tool that is designed to work with PEP 517/518 compliant projects
71
+ and it is much faster than "reference" ``pip `` tool. It has extensive support to not only create development
72
+ environment but also to manage python versions, development environments, workspaces and Python tools used
73
+ to develop Airflow (via ``uv tool `` command - such as ``pre-commit `` and others, you can also use ``uv tool ``
74
+ to install ``breeze `` - containerized development environment for Airflow that we use to reproduce the
75
+ CI environment locally and to run release-management and certain development tasks.
76
+
77
+ You can read more about ``uv `` in `UV Getting started <https://docs.astral.sh/uv/getting-started/ >`_ but
78
+ below you will find a few typical steps to get you started with ``uv ``.
79
+
80
+ Installing uv
81
+ .............
82
+
83
+ You can follow the `installation instructions <https://docs.astral.sh/uv/getting-started/installation/ >`_ to install
84
+ ``uv `` on your system. Once you have ``uv `` installed, you can do all the environment preparation tasks using
85
+ ``uv `` commands.
86
+
87
+ Installing Python versions
88
+ ..........................
89
+
90
+ You can install Python versions using ``uv python install `` command. For example, to install Python 3.9.7, you can run:
91
+
92
+ .. code :: bash
93
+
94
+ uv python install 3.9.7
95
+
96
+ This is optional step - ``uv `` will automatically install the Python version you need when you create a virtualenv.
97
+
98
+ Creating virtualenvs with uv
99
+ ............................
100
+
101
+ .. code :: bash
102
+
103
+ uv venv
104
+
105
+ This will create a default venv in your project's ``.venv `` directory. You can also create a venv
106
+ with a specific Python version by running:
107
+
108
+ .. code :: bash
109
+
110
+ uv venv --python 3.9.7
66
111
67
- The simplest way to install Airflow in local virtualenv is to use `` pip `` :
112
+ You can also create a venv with a different venv directory name by running :
68
113
69
114
.. code :: bash
70
115
71
- pip install -e " .[devel,<OTHER EXTRAS>]" # for example: pip install -e ".[devel,google,postgres]"
116
+ uv venv .my-venv
117
+
118
+ However ``uv `` creation/re-creation of venvs is so fast that you can easily create and delete venvs as needed.
119
+ So usually you do not need to have more than one venv and recreate it as needed - for example when you
120
+ need to change the python version.
121
+
122
+ Syncing project (including providers) with uv
123
+ .............................................
124
+
125
+ In a project like airflow it's important to have a consistent set of dependencies across all developers.
126
+ You can use ``uv sync `` to install dependencies from ``pyproject.toml `` file. This will install all dependencies
127
+ from the ``pyproject.toml `` file in the current directory.
128
+
129
+ .. code :: bash
130
+
131
+ uv sync
132
+
133
+ If you also need to install development and provider dependencies you can specify extras for that providers:
134
+
135
+ .. code :: bash
136
+
137
+ uv sync --extra devel --extra devel-tests --extra google
138
+
139
+ This will synchronize all extras that you need for development and testing of Airflow and google provider
140
+ dependencies - including their runtime dependencies.
141
+
142
+ .. code :: bash
143
+
144
+ uv sync --all-extras
145
+
146
+ This will synchronize all extras of airflow (this might require some system dependencies to be installed).
147
+
148
+
149
+ Creating and installing airflow with other build-frontends
150
+ ----------------------------------------------------------
151
+
152
+ While ``uv `` uses ``workspace `` feature to synchronize both Airflow and Providers in a single sync
153
+ command, you can still use other frontend tools (such as ``pip ``) to install Airflow and Providers
154
+ and to develop them without relying on ``sync `` and ``workspace `` features of ``uv ``. Below chapters
155
+ describe how to do it with ``pip ``.
156
+
157
+ Installing Airflow with pip
158
+ ...........................
159
+
160
+ Since Airflow follows the standards define by the packaging community, we are not bound with
161
+ ``uv `` as the only tool to manage virtualenvs - and you can use any other compliant frontends to install
162
+ airflow for development. The standard way of installing environment with dependencies necessary to
163
+ run tests is to use ``pip `` to install airflow dependencies:
164
+
165
+ .. code :: bash
166
+
167
+ pip install -e " .[devel,devel-tests,<OTHER EXTRAS>]" # for example: pip install -e ".[devel,devel-tests,google,postgres]"
72
168
73
169
This will install Airflow in 'editable' mode - where sources of Airflow are taken directly from the source
74
170
code rather than moved to the installation directory. You need to run this command in the virtualenv you
75
171
want to install Airflow in - and you need to have the virtualenv activated.
76
172
77
- While you can use any virtualenv manager, we recommend using `Hatch <https://hatch.pypa.io/latest/ >`__
78
- as your development environment front-end, and we already use Hatch backend ``hatchling `` for Airflow.
79
-
80
- Hatchling is automatically installed when you build Airflow but since airflow build system uses
81
- ``PEP `` compliant ``pyproject.toml `` file, you can use any front-end build system that supports
82
- ``PEP 517 `` and ``PEP 518 ``. You can also use ``pip `` to install Airflow in editable mode.
83
-
84
173
Extras (optional dependencies)
85
174
..............................
86
175
@@ -145,169 +234,6 @@ both runtime and development dependencies of the google provider.
145
234
The second one installs providers source code in development mode, so that modifications
146
235
to the code are automatically reflected in your installed virtualenv.
147
236
148
- Using Hatch
149
- -----------
150
-
151
- Airflow uses `hatch <https://hatch.pypa.io/ >`_ as a build and development tool of choice. It is one of popular
152
- build tools and environment managers for Python, maintained by the Python Packaging Authority.
153
- It is an optional tool that is only really needed when you want to build packages from sources, but
154
- it is also very convenient to manage your Python versions and virtualenvs.
155
-
156
- Airflow project contains some pre-defined virtualenv definitions in ``pyproject.toml `` that can be
157
- easily used by hatch to create your local venvs. This is not necessary for you to develop and test
158
- Airflow, but it is a convenient way to manage your local Python versions and virtualenvs.
159
-
160
- Installing Hatch
161
- ................
162
-
163
- You can install hatch using various other ways (including Gui installers).
164
-
165
- Example using ``pipx ``:
166
-
167
- .. code :: bash
168
-
169
- pipx install hatch
170
-
171
- We recommend using ``pipx `` as you can manage installed Python apps easily and later use it
172
- to upgrade ``hatch `` easily as needed with:
173
-
174
- .. code :: bash
175
-
176
- pipx upgrade hatch
177
-
178
- Using Hatch to manage your Python versions
179
- ..........................................
180
-
181
- You can also use hatch to install and manage airflow virtualenvs and development
182
- environments. For example, you can install Python 3.10 with this command:
183
-
184
- .. code :: bash
185
-
186
- hatch python install 3.10
187
-
188
- or install all Python versions that are used in Airflow:
189
-
190
- .. code :: bash
191
-
192
- hatch python install all
193
-
194
- Manage your virtualenvs with Hatch
195
- ..................................
196
-
197
- Airflow has some pre-defined virtualenvs that you can use to develop and test airflow.
198
- You can see the list of available envs with:
199
-
200
- .. code :: bash
201
-
202
- hatch env show
203
-
204
- This is what it shows currently:
205
-
206
- +-------------+---------+---------------------------------------------------------------+
207
- | Name | Type | Description |
208
- +=============+=========+===============================================================+
209
- | default | virtual | Default environment with Python 3.9 for maximum compatibility |
210
- +-------------+---------+---------------------------------------------------------------+
211
- | airflow-39 | virtual | Environment with Python 3.9. No devel installed. |
212
- +-------------+---------+---------------------------------------------------------------+
213
- | airflow-310 | virtual | Environment with Python 3.10. No devel installed. |
214
- +-------------+---------+---------------------------------------------------------------+
215
- | airflow-311 | virtual | Environment with Python 3.11. No devel installed |
216
- +-------------+---------+---------------------------------------------------------------+
217
- | airflow-312 | virtual | Environment with Python 3.12. No devel installed |
218
- +-------------+---------+---------------------------------------------------------------+
219
-
220
- The default env (if you have not used one explicitly) is ``default `` and it is a Python 3.9
221
- virtualenv for maximum compatibility. You can install devel set of dependencies with it
222
- by running:
223
-
224
- .. code :: bash
225
-
226
- pip install -e " .[devel]"
227
-
228
- After entering the environment.
229
-
230
- The other environments are just bare-bones Python virtualenvs with Airflow core requirements only,
231
- without any extras installed and without any tools. They are much faster to create than the default
232
- environment, and you can manually install either appropriate extras or directly tools that you need for
233
- testing or development.
234
-
235
- .. code :: bash
236
-
237
- hatch env create
238
-
239
- You can create specific environment by using them in create command:
240
-
241
- .. code :: bash
242
-
243
- hatch env create airflow-310
244
-
245
- You can install extras in the environment by running pip command:
246
-
247
- .. code :: bash
248
-
249
- hatch -e airflow-310 run -- pip install -e " .[devel,google]"
250
-
251
- And you can enter the environment with running a shell of your choice (for example zsh) where you
252
- can run any commands
253
-
254
- .. code :: bash
255
-
256
- hatch -e airflow-310 shell
257
-
258
-
259
- Once you are in the environment (indicated usually by updated prompt), you can just install
260
- extra dependencies you need:
261
-
262
- .. code :: bash
263
-
264
- [~/airflow] [airflow-310] pip install -e " .[devel,google]"
265
-
266
-
267
- You can also see where hatch created the virtualenvs and use it in your IDE or activate it manually:
268
-
269
- .. code :: bash
270
-
271
- hatch env find airflow-310
272
-
273
- You will get path similar to:
274
-
275
- .. code ::
276
-
277
- /Users/jarek/Library/Application Support/hatch/env/virtual/apache-airflow/TReRdyYt/apache-airflow
278
-
279
- Then you will find ``python `` binary and ``activate `` script in the ``bin `` sub-folder of this directory and
280
- you can configure your IDE to use this python virtualenv if you want to use that environment in your IDE.
281
-
282
- You can also set default environment name by HATCH_ENV environment variable.
283
-
284
- You can clean the env by running:
285
-
286
- .. code :: bash
287
-
288
- hatch env prune
289
-
290
- More information about hatch can be found in `Hatch: Environments <https://hatch.pypa.io/latest/environment/ >`__
291
-
292
- Using Hatch to build your packages
293
- ..................................
294
-
295
- You can use hatch to build installable package from the airflow sources. Such package will
296
- include all metadata that is configured in ``pyproject.toml `` and will be installable with pip.
297
-
298
- The packages will have pre-installed dependencies for providers that are always
299
- installed when Airflow is installed from PyPI. By default both ``wheel `` and ``sdist `` packages are built.
300
-
301
- .. code :: bash
302
-
303
- hatch build
304
-
305
- You can also build only ``wheel `` or ``sdist `` packages:
306
-
307
- .. code :: bash
308
-
309
- hatch build -t wheel
310
- hatch build -t sdist
311
237
312
238
Local and Remote Debugging in IDE
313
239
---------------------------------
@@ -388,11 +314,11 @@ run the command above and commit the changes to ``pyproject.toml``. Then running
388
314
install the dependencies automatically when you create or switch to a development environment.
389
315
390
316
391
- Installing recommended version of dependencies
392
- ----------------------------------------------
317
+ Installing "golden" version of dependencies
318
+ -------------------------------------------
393
319
394
320
Whatever virtualenv solution you use, when you want to make sure you are using the same
395
- version of dependencies as in main, you can install recommended version of the dependencies by using
321
+ version of dependencies as in main, you can install recommended version of the dependencies by using pip:
396
322
constraint-python<PYTHON_MAJOR_MINOR_VERSION>.txt files as ``constraint `` file. This might be useful
397
323
to avoid "works-for-me" syndrome, where you use different version of dependencies than the ones
398
324
that are used in main, CI tests and by other contributors.
@@ -405,6 +331,14 @@ all basic devel requirements and requirements of google provider as last success
405
331
pip install -e " .[devel,google]" \
406
332
--constraint " https://raw.githubusercontent.com/apache/airflow/constraints-main/constraints-source-providers-3.9.txt"
407
333
334
+ Or with ``uv ``:
335
+
336
+ .. code :: bash
337
+
338
+ uv pip install -e " .[devel,google]" \
339
+ --constraint " https://raw.githubusercontent.com/apache/airflow/constraints-main/constraints-source-providers-3.9.txt"
340
+
341
+
408
342
Make sure to use latest main for such installation, those constraints are "development constraints" and they
409
343
are refreshed several times a day to make sure they are up to date with the latest changes in the main branch.
410
344
0 commit comments