You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Modern Python package management uses a `pyproject.toml` that was first introduced in [PEP 518](https://peps.python.org/pep-0518/).
53
51
This file contains build system requirements and information, which are used by pip to build the package, and tool configurations.
54
52
For more details please have a look at [pip's description of the pyproject.toml file](https://pip.pypa.io/en/stable/reference/build-system/pyproject-toml/).
55
53
It also serves as a single point of truth to define test environments and how docs are built by leveraging
56
54
the [hatch][] project manager, but more about that in the [contributing guide](contributing.md).
57
55
58
-
####Important metadata fields
56
+
### Important metadata fields
59
57
60
58
The `[project]` section in the `pyproject.toml` file defines several important metadata fields that might require editing.
61
59
For example, the `name`, `description`, `authors` fields could need updates as the project evolves.
62
60
Especially, the `version` field needs to be adapted if newer versions of the package are to be released.
63
61
See {ref}`vcs-based-versioning` for more details.
64
62
65
-
####Dependency management
63
+
### Dependency management
66
64
67
65
Package dependencies can be added to the `dependencies` of the `[project]` section.
68
66
You can constrain versions using any of `>=`, `>`, `<`, `<=`, `==`, `!=`, and `~=`.
@@ -72,7 +70,7 @@ As another example, if there is a known buggy version, you could exclude it like
72
70
Further optional dependencies are defined in the `[project.optional-dependencies]` section such as dependencies only for tests (`test`).
73
71
All dependencies listed in such optional dependency groups can then be installed by specifying them like: `pip install <package-name>[test]`.
74
72
75
-
####Tool configurations
73
+
### Tool configurations
76
74
77
75
The `pyproject.toml` file also serves as single configuration file for many tools such as many {ref}`pre-commit`.
78
76
For example, the line length for auto-formatting can be configured as follows:
@@ -84,7 +82,7 @@ line-length = 120
84
82
85
83
[hatch]: https://hatch.pypa.io/latest/
86
84
87
-
###Coverage tests with _Codecov_
85
+
## Coverage tests with _Codecov_
88
86
89
87
Coverage tells what fraction of the code is "covered" by unit tests,
90
88
thereby encouraging contributors to [write tests](contributing.md#writing-tests).
@@ -102,7 +100,7 @@ To set it up, simply go to the [codecov app][] page and follow the instructions
We recommend using [readthedocs.org][] (RTD) to build and host the documentation for your project.
108
106
To enable readthedocs, head over to [their website][readthedocs.org] and sign in with your GitHub account.
@@ -123,7 +121,7 @@ See a guide [here](https://docs.readthedocs.io/en/stable/guides/importing-privat
123
121
124
122
(github-actions)=
125
123
126
-
###Github Actions
124
+
## Github Actions
127
125
128
126
[GitHub Actions][] is a continuous integration (CI)/continuous development (CD) automation tool that enables workflows for building, testing, and deploying code directly from a GitHub repository.
129
127
It uses YAML-based configuration files to define jobs and steps, which can be triggered by events like pushes, pull requests, or scheduled runs.
@@ -148,7 +146,7 @@ There you can see the execution history, logs, and (re-)trigger workflows manual
148
146
(automating-pypi-released-using-github-actions)=
149
147
(configuring-the-github-workflow)=
150
148
151
-
###Automating the PyPI release using GitHub actions
149
+
## Automating the PyPI release using GitHub actions
152
150
153
151
Tags adhering to `"*.*.*"` that are pushed to the `main` branch will trigger the release Github workflow that automatically builds and uploads the Python package to [PyPI][].
154
152
@@ -170,15 +168,15 @@ For more details, please refer to the official [PyPI guide for setting up truste
170
168
171
169
(pre-commit)=
172
170
173
-
###Pre-commit checks
171
+
## Pre-commit checks
174
172
175
173
[Pre-commit][] checks are fast programs that check code for errors, inconsistencies and code styles, before the code is committed.
176
174
177
175
This template uses a number of pre-commit checks.
178
176
In this section we'll detail what is used, where they're defined, and how to modify these checks.
179
177
180
178
181
-
####Pre-commit CI
179
+
### Pre-commit CI
182
180
183
181
We recommend setting up [pre-commit.ci][] to enforce consistency checks on every commit and pull-request.
184
182
@@ -189,7 +187,7 @@ You may choose to enable the service for an entire organization or on a per-repo
189
187
Once authorized, pre-commit.ci should automatically be activated.
190
188
191
189
192
-
####Overview of pre-commit hooks used by the template
190
+
### Overview of pre-commit hooks used by the template
193
191
194
192
The following pre-commit hooks are for code style and format:
195
193
@@ -230,19 +228,19 @@ The following pre-commit hooks are for errors and inconsistencies:
0 commit comments