The only key currently recognised is extensions.
This should be a map of key-value pairs mapping the extension name to a resolver.
# pyproject.toml
[tool.hatch.build.targets.wheel.hooks.buildext]
dependencies = ["hatch-buildext"]
[tool.hatch.build.targets.wheel.hooks.buildext.extensions]
libsome = "path.to.resolver"
libother = "path.to.another"For instance, if using src layout, the directory structure could look as follows:
.
├── LICENSE.txt
├── README.md
├── pyproject.toml
├── src
│ ├── resolvers
│ │ ├── lib_a.py
│ │ └── lib_b.py
│ ├── liba
│ │ ├── foo.h
│ │ └── foo.c
│ ├── libb
│ │ ├── bar.h
│ │ └── bar.c
│ └── mypackage
│ ├── __about__.py
│ ├── __init__.py
│ ├── ...
│ └── core.py
└── tests
├── __init__.py
├── conftest.py
├── ...
└── test_core.pyThen, if that you want to include both libraries as module extensions in mypackage,
the extensions configuration would look as follows:
[tool.hatch.build.targets.wheel.hooks.buildext.extensions]
"mypackage.lib_a" = "src.resolvers.lib_a"
"mypackage.lib_b" = "src.resolvers.lib_b"Warning
The configuration may change at any time until this package is stable.
Resolvers may implement or omit any part of the interface here. Each function will be passed the root of of the project directory while building, in order to make it easier to provide paths to build requirements in the project tree.
The meaning of these functions are identical to those in the setuptools Extension API.
Warning
The interface may change at any time until this package is stable.
hatch-buildext is distributed under the terms of the Apache-2.0 license.