Skip to content

Commit 4fef077

Browse files
authored
Merge pull request #228 from ucodery/hatch-backend
Add: text on Hatch backend compatibility
2 parents 22e953b + 969e0b1 commit 4fef077

File tree

3 files changed

+34
-6
lines changed

3 files changed

+34
-6
lines changed

package-structure-code/complex-python-package-builds.md

Lines changed: 31 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -8,12 +8,40 @@ In the future, we want to provide resources for packaging workflows that require
88
## Pure Python Packages vs. packages with extensions in other languages
99

1010
You can classify Python package complexity into three general categories. These
11-
categories can in turn help you select the correct package front-end and
12-
back-end tools.
11+
categories can in turn help you select the correct package frontend and
12+
backend tools.
1313

1414
1. **Pure-python packages:** these are packages that only rely on Python to function. Building a pure Python package is simpler. As such, you can chose a tool below that has the features that you want and be done with your decision!
1515

16-
2. **Python packages with non-Python extensions:** These packages have additional components called extensions written in other languages (such as C or C++). If you have a package with non-python extensions, then you need to select a build back-end tool that allows you to add additional build steps needed to compile your extension code. Further, if you wish to use a front-end tool to support your workflow, you will need to select a tool that supports additional build setups. In this case, you could use setuptools. However, we suggest that you chose build tool that supports custom build steps such as Hatch with Hatchling or PDM. PDM is an excellent choice as it allows you to also select your build back-end of choice. We will discuss this at a high level on the complex builds page.
16+
2. **Python packages with non-Python extensions:** These packages have additional components called extensions written in other languages (such as C or C++). If you have a package with non-Python extensions, then you need to select a build backend tool that allows additional build steps needed to compile your extension code. Further, if you wish to use a frontend tool to support your workflow, you will need to select a tool that supports additional build setups. We suggest that you chose build tool that supports custom build steps like Hatch.
1717

1818
3. **Python packages that have extensions written in different languages (e.g. Fortran and C++) or that have non Python dependencies that are difficult to install (e.g. GDAL)** These packages often have complex build steps (more complex than a package with just a few C extensions for instance). As such, these packages require tools such as [scikit-build](https://scikit-build.readthedocs.io/en/latest/)
1919
or [meson-python](https://mesonbuild.com/Python-module.html) to build. NOTE: you can use meson-python with PDM.
20+
21+
## Mixing frontend and backend projects
22+
23+
It is sometimes necessary or desirable to use a build frontend with an alternative build-backend.
24+
This is because some frontends do not have a default backend (`build`), and this choice is placed on the maintainer.
25+
Other backends (`hatch`) have a preferred backend (`hatchling`) but allow the maintainer to migrate to another, while
26+
some backends (`poetry`) only work with a single backend (`poetry-core`). Refer to (#python-package-build-tools) for
27+
more information about frontend and backend compatibility.
28+
29+
In this packaging guide we recommend using `hatch` along with its preferred backend `hatchling`. While this will be
30+
suitable for most packages, an alternate backend may be used with Hatch if needed when creating an extension module.
31+
A Python extension module is one that is made up, either in part or entirely, of compiled code. In this case the
32+
backend chosen (such as `meson-python`) must know how to compile the extension language and bind it to Python.
33+
`hatchling` does not know how to do this all on its own and must either make use of
34+
[plugins](https://hatch.pypa.io/1.9/plugins/about/) or be replaced by a backend that is already capable of building
35+
extension modules.
36+
37+
In order to use a different backend you will need to edit your project's `pyproject.toml`. If you have a
38+
`pyproject.toml` generated by the `hatch` command, or from following the packaging tutorial, you may have
39+
to make a change like this
40+
41+
```diff
42+
[build-system]
43+
-requires = ["hatchling"]
44+
+requires = ["meson-python"]
45+
-build-backend = "hatchling.build"
46+
+build-backend = "mesonpy"
47+
```

package-structure-code/python-package-build-tools.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -344,7 +344,7 @@ as building your documentation locally. This means that you could potentially dr
344344
:widths: 20,5,50
345345
:delim: "|"
346346
347-
Use Other Build Backends|✅ | Switching out build back-ends is not currently an option with Hatch. However, this feature is planned for a future release.
347+
Use Other Build Backends|✅ | Hatch is used with the backend Hatchling by default, but allows you to use another backend by switching the declaration in pyproject.toml.
348348
Dependency management|✖| Currently you have to add dependencies manually with Hatch. However a feature to support dependencies management may be added in a future release.
349349
Environment Management |✅ | Hatch supports Python virtual environments. If you wish to use other types of environments such as Conda, you will need to [install a plugin such as hatch-conda for conda support](https://github.com/OldGrumpyViking/hatch-conda).
350350
Publish to PyPI and test PyPI|✅|Hatch supports publishing to both test PyPI and PyPI
@@ -355,7 +355,7 @@ Install your package in editable mode|✅| Hatch will install your package into
355355
Build your sdist and wheel distributions|✅| Hatch will build the sdist and wheel distributions
356356
✨Matrix environment creation to support testing across Python versions✨|✅| The matrix environment creation is a feature that is unique to Hatch in the packaging ecosystem. This feature is useful if you wish to test your package locally across Python versions (instead of using a tool such as tox).
357357
✨[Nox / MAKEFILE like functionality](https://hatch.pypa.io/latest/environment/#selection)✨| ✅| This feature is also unique to Hatch. This functionality allows you to create workflows in the **pyproject.toml** configuration to do things like serve docs locally and clean your package build directory. This means you may have one less tool in your build workflow.
358-
✨A flexible build back-end: **hatchling**✨| ✅| **The hatchling build back-end offered by the maintainer of Hatch allows developers to easily build plugins to support custom build steps when packaging.
358+
✨A flexible build backend: **hatchling**✨| ✅| **The hatchling build backend offered by the maintainer of Hatch allows developers to easily build plugins to support custom build steps when packaging.
359359
360360
```
361361

package-structure-code/python-package-versions.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -179,7 +179,7 @@ your package version.
179179
To use **hatch_vcs** you will need to use the **hatchling** build back end.
180180

181181
```{tip}
182-
Hatchling can also be used any of the modern build tools
182+
Hatchling can also be used with any of the modern build tools
183183
including **Flit** and **PDM** if you prefer those for your day to
184184
day workflow.
185185
```

0 commit comments

Comments
 (0)