Pass config_settings from build frontend to builders

[brandon-avantus]

As a Python packager writing custom hatchling build hooks (using hatch_build.py), I would like hatchling to support passing config_settings from build frontends that support it to hatchling builders so that users can customize certain aspects of the build experience (i.e., build jobs, compiler choice, etc.) using the command-line options provided by build frontends.

PEP 517 defines a config_settings dictionary in the backend hooks specifications for passing configuration from build frontends. Many build frontends already support passing in config_settings using the -C/--config-settings command-line option.

• uv build
• pip install
• pip wheel
• pyproject-build (from the build package)

Currently, hatchling does not pass config_settings on to builders. I finally realized that the reluctance to implement such a feature in hatch, as indicated by responses in #1072, stem from the ambiguity in how frontends should implement the feature. What I'm suggesting here is not that we add support to the hatch frontend, but that we provide the backend with settings from frontends that already support it.

See #1072

Please let me know if anything should be added to the documentation or if additional tests would be helpful.

[brandon-avantus]

I just realized this is incomplete. I need to get the config_settings all the way to the BuildHookInterface. I'll update the PR as soon as possible.

[brandon-avantus]

Passing config_settings to hook interfaces is now complete. This PR is ready for review. Thanks for your patience.

[cjames23]

Currently, hatchling does not pass config_settings on to builders. I finally realized that the reluctance to implement such a feature in hatch, as indicated by responses in #1072, stem from the ambiguity in how frontends should implement the feature. What I'm suggesting here is not that we add support to the hatch frontend, but that we provide the backend with settings from frontends that already support it.

I do not think the reluctance is fully this. I wont speak for Ofek but in general hatchling is meant to serve as a build backend that handles things out of the box for you. And this line from the config_settings section of the PEP somewhat go against our philosophy with hatchling and hatch:

it’s up to users to make sure that they pass options which make sense for the particular build backend and package that they are building.

I would point to https://hatch.pypa.io/latest/why/#build-backend which talks about the why of hatchling and what it is trying to do that other build backends might not offer.

[virtuald]

@cjames23 just copying my comment from #1072

I'm thinking about writing a hatch build plugin to run an external build system to build binary dependencies (and I see that scikit-build-core is doing that too for cmake).

It seems to me that if I wanted to enable/disable debugging symbols for my build, the only mechanism that's available is either modifying pyproject.toml each time I want to change the setting, or by setting an environment variable. I'm new to hatchling, is there an alternative way to accomplish that? If not, having access to config_settings would be useful for this sort of thing.

I understand that "hatchling is meant to serve as a build backend that handles things out of the box for you". This is a good ideal, but I don't really understand how hatchling will be able to anticipate my needs for a hatchling plugin that wraps a build system like cmake or meson. A build system plugin needs the config_settings escape hatch for configuring things like debug/release builds. As the zen of python says...

Special cases aren't special enough to break the rules.
Although practicality beats purity.

Of course, https://hatch.pypa.io/latest/why/#build-backend seems to imply that it doesn't want to support any kind of building extension modules:

If building extension modules is required then it is recommended that you continue using setuptools, or even other backends that specialize in interfacing with compilers.

I quite like the hatchling plugin system, its useful for composing different types of functionality together to build a python wheel, and allows me to more easily do things that are more annoying to do in the build system.

---

For now, I'm continuing to use the hacky workaround I posted in my hatch plugin that wraps meson. It works fine for me, but I'd rather official support exist instead.