This entry describes a common pattern for creating a custom metadata hook within Hatchling (version 1.x), enabling automatic generation or modification of project extras. While 'hatchling-autoextras-hook' exists as a PyPI package, its low version and lack of dedicated documentation suggest it's more of an illustrative or niche implementation rather than a widely used standalone plugin. The typical approach involves implementing a custom metadata hook using `hatchling` itself, which allows dynamic modification of project metadata during the build process, including `optional-dependencies` (extras). Hatchling is a modern, extensible build backend for Python projects, with a rapid release cadence.
pip install hatchlingVerified import paths — ran on the pinned version, not inferred.
This example demonstrates how to set up a custom metadata hook (`hatch_build.py`) to dynamically add or modify extras (optional-dependencies) in your `pyproject.toml`. The `dynamic = ["optional-dependencies"]` declaration is crucial. The hook's `update` method receives the project's metadata and can modify it in-place. Configuration can be passed to the hook via `pyproject.toml`.
If your custom metadata hook dynamically adds dependencies that are required *by the build environment itself*, you must ensure these are either statically declared in `build-system.requires` or that your hook explicitly manages adding them to the build environment's path/dependencies if that's your intended use case, typically by manually adjusting `sys.path` within the hook or using a build hook in conjunction for runtime dependencies.
Always declare any metadata fields that your hook modifies (e.g., `optional-dependencies`, `dependencies`, `authors`) in the `[project] dynamic = [...]` section of your `pyproject.toml`. Failure to do so will result in your dynamic changes being ignored. If a field is declared `dynamic`, it must *not* have a static definition in `pyproject.toml`.
Be aware that for custom hooks defined by path, the logical name for configuration purposes is always `custom`. Any `PLUGIN_NAME` defined in your Python class will not alter this behavior. This also means you can only have one `custom` metadata hook per project defined this way.
If your metadata hook needs to access code from your package, avoid direct `import your_package`. Instead, consider adding your package's source directory (e.g., `src/`) to `sys.path` within the hook, or refactor the logic to be standalone and not depend on the partially built package. If the dependencies are truly build-time only, they should be in `build-system.requires`.
No resource links recorded.