|
4 | 4 | Writing your ``pyproject.toml``
|
5 | 5 | ===============================
|
6 | 6 |
|
7 |
| -``pyproject.toml`` is a configuration file used by packaging tools. Most |
8 |
| -:term:`build backends <build backend>` [#poetry-special]_ allow you to specify |
9 |
| -your project's basic metadata, such as the dependencies, your name, etc., |
10 |
| -in the ``[project]`` table of your ``pyproject.toml``. |
| 7 | +``pyproject.toml`` is a configuration file used by packaging tools, as |
| 8 | +well as other tools such as linters, type checkers, etc. There are |
| 9 | +three possible TOML tables in this file. |
| 10 | + |
| 11 | +- The ``[build-system]`` table is **strongly recommended**. It allows |
| 12 | + you to declare which :term:`build backend` you use and which other |
| 13 | + dependencies are needed to build your project. |
| 14 | + |
| 15 | +- The ``[project]`` table is the format that most build backends use to specify |
| 16 | + your project's basic metadata, such as the dependencies, your name, etc. |
| 17 | + |
| 18 | +- The ``[tool]`` table has tool-specific subtables, e.g., ``[tool.hatch]``, |
| 19 | + ``[tool.black]``, ``[tool.mypy]``. We only touch upon this table here because |
| 20 | + its contents are defined by each tool. Consult the particular tool's |
| 21 | + documentation to know what it can contain. |
11 | 22 |
|
12 | 23 | .. note::
|
13 | 24 |
|
14 |
| - You may have heard of ``setup.py`` and ``setup.cfg`` for the setuptools_ |
15 |
| - build backend. For new projects, it is recommended to use ``pyproject.toml`` |
16 |
| - for basic metadata, and keep ``setup.py`` only if some programmatic configuration |
17 |
| - is needed (especially building C extensions). However, putting basic project |
18 |
| - metadata in ``setup.py`` or ``setup.cfg`` is still valid. See |
| 25 | + There is a significant difference between the ``[build-system]`` and |
| 26 | + ``[project]`` tables. The former should always be present, regardless of |
| 27 | + which build backend you use (since it *defines* the tool you use). The latter |
| 28 | + is understood by *most* build backends, but some build backends use a |
| 29 | + different format. |
| 30 | + |
| 31 | + At the time of writing this (November 2023), Poetry_ is a notable build |
| 32 | + backend that does not use the ``[project]`` table (it uses the |
| 33 | + ``[tool.poetry]`` table instead). |
| 34 | + |
| 35 | + Also, the setuptools_ build backend supports both the ``[project]`` table, |
| 36 | + and the older format in ``setup.cfg`` or ``setup.py``. For new projects, it |
| 37 | + is recommended to use the ``[project]`` table, and keep ``setup.py`` only if |
| 38 | + some programmatic configuration is needed (such as building C extensions), |
| 39 | + but the ``setup.cfg`` and ``setup.py`` formats are still valid. See |
19 | 40 | :ref:`setup-py-deprecated`.
|
20 | 41 |
|
21 | 42 |
|
| 43 | + |
| 44 | +Declaring the build backend |
| 45 | +=========================== |
| 46 | + |
| 47 | +The ``[build-system]`` table contains a ``build-backend`` key, which specifies |
| 48 | +the build backend to be used. It also contains a ``requires`` key, which is a |
| 49 | +list of dependencies needed to build the project -- this is typically just the |
| 50 | +build backend package, but it may also contain additional dependencies. You can |
| 51 | +also constrain the versions, e.g., ``requires = ["setuptools >= 61.0"]``. |
| 52 | + |
| 53 | +Usually, you'll just copy what your build backend's documentation |
| 54 | +suggests (after :ref:`choosing your build backend <choosing-build-backend>`). |
| 55 | +Here are the values for some common build backends: |
| 56 | + |
| 57 | +.. tab:: Hatchling |
| 58 | + |
| 59 | + .. code-block:: toml |
| 60 | +
|
| 61 | + [build-system] |
| 62 | + requires = ["hatchling"] |
| 63 | + build-backend = "hatchling.build" |
| 64 | +
|
| 65 | +.. tab:: setuptools |
| 66 | + |
| 67 | + .. code-block:: toml |
| 68 | +
|
| 69 | + [build-system] |
| 70 | + requires = ["setuptools >= 61.0"] |
| 71 | + build-backend = "setuptools.build_meta" |
| 72 | +
|
| 73 | +.. tab:: Flit |
| 74 | + |
| 75 | + .. code-block:: toml |
| 76 | +
|
| 77 | + [build-system] |
| 78 | + requires = ["flit_core >= 3.4"] |
| 79 | + build-backend = "flit_core.buildapi" |
| 80 | +
|
| 81 | +.. tab:: PDM |
| 82 | + |
| 83 | + .. code-block:: toml |
| 84 | +
|
| 85 | + [build-system] |
| 86 | + requires = ["pdm-backend"] |
| 87 | + build-backend = "pdm.backend" |
| 88 | +
|
| 89 | +
|
| 90 | +
|
22 | 91 | Static vs. dynamic metadata
|
23 | 92 | ===========================
|
24 | 93 |
|
25 |
| -Most of the time, you will directly write the value of a field in |
26 |
| -``pyproject.toml``. For example: ``requires-python = ">= 3.8"``, or |
27 |
| -``version = "1.0"``. |
| 94 | +The rest of this guide is devoted to the ``[project]`` table. |
| 95 | + |
| 96 | +Most of the time, you will directly write the value of a ``[project]`` |
| 97 | +field. For example: ``requires-python = ">= 3.8"``, or ``version = |
| 98 | +"1.0"``. |
28 | 99 |
|
29 | 100 | However, in some cases, it is useful to let your build backend compute
|
30 | 101 | the metadata for you. For example: many build backends can read the
|
@@ -316,6 +387,10 @@ A full example
|
316 | 387 |
|
317 | 388 | .. code-block:: toml
|
318 | 389 |
|
| 390 | + [build-system] |
| 391 | + requires = ["hatchling"] |
| 392 | + build-backend = "hatchling.build" |
| 393 | +
|
319 | 394 | [project]
|
320 | 395 | name = "spam-eggs"
|
321 | 396 | version = "2020.0.0"
|
@@ -370,10 +445,6 @@ A full example
|
370 | 445 |
|
371 | 446 | ------------------
|
372 | 447 |
|
373 |
| -.. [#poetry-special] At the time of this writing (November 2023), Poetry_ |
374 |
| - is a notable exception. It uses its own format for this metadata, in |
375 |
| - the ``[tool.poetry]`` table. |
376 |
| -
|
377 | 448 | .. [#requires-python-upper-bounds] Think twice before applying an upper bound
|
378 | 449 | like ``requires-python = "<= 3.10"`` here. `This blog post <requires-python-blog-post_>`_
|
379 | 450 | contains some information regarding possible problems.
|
|
0 commit comments