@@ -15,11 +15,10 @@ three possible TOML tables in this file.
15
15
- The ``[project] `` table is the format that most build backends use to specify
16
16
your project's basic metadata, such as the dependencies, your name, etc.
17
17
18
- - The ``[tool] `` table has arbitrary subtables corresponding to tools, whether
19
- packaging-related or not, e.g., ``[tool.hatch] ``, ``[tool.black] ``,
20
- ``[tool.mypy] ``. We only touch upon this table here because its contents are
21
- entirely tool-specific. Consult each tool's documentation to know what it can
22
- contain.
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.
23
22
24
23
.. note ::
25
24
@@ -36,7 +35,7 @@ three possible TOML tables in this file.
36
35
Also, the setuptools _ build backend supports both the ``[project] `` table,
37
36
and the older format in ``setup.cfg `` or ``setup.py ``. For new projects, it
38
37
is recommended to use the ``[project] `` table, and keep ``setup.py `` only if
39
- some programmatic configuration is needed (especially building C extensions),
38
+ some programmatic configuration is needed (such as building C extensions),
40
39
but the ``setup.cfg `` and ``setup.py `` formats are still valid. See
41
40
:ref: `setup-py-deprecated `.
42
41
@@ -88,12 +87,12 @@ Here are the values for some common build backends:
88
87
build-backend = "pdm.backend"
89
88
90
89
91
- The rest of this guide is devoted to the ``[project] `` table.
92
-
93
90
94
91
Static vs. dynamic metadata
95
92
===========================
96
93
94
+ The rest of this guide is devoted to the ``[project] `` table.
95
+
97
96
Most of the time, you will directly write the value of a ``[project] ``
98
97
field. For example: ``requires-python = ">= 3.8" ``, or ``version =
99
98
"1.0" ``.
0 commit comments