hatch-buildext

Table of Contents

• Usage
  • Example
  • Resolvers
• License

Usage

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"

Example

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.py

Then, 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

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.

License

hatch-buildext is distributed under the terms of the Apache-2.0 license.