PEP 660 and setuptools

[abravalheri (Anderson Bravalheri)]

Thank you very much Paul for looking into this.

@pf_moore

1. Is config_settings supposed to be constant across all hook calls? See this thread for more detail.

I think this is the most straightforward way of dealing with this parameter. In general terms, I believe that config_settings is needed for both build_XXX and prepare_metadata_for_build_XXX hooks (at least)^[1] so it make sense to use the same dictionary across all hook calls.

@pf_moore

2. Are backends expected to ignore settings they don’t recognise? This is important because frontends like pip can be building multiple projects at once (in the case of dependencies, this may even be unavoidable) and those projects may use different backends.

I am in favour of this approach for the keys in config_settings.
I would say that backends may decide to warn the user about keys it cannot recognise (just for informational purposes), but not fail. This seems to also inline with the existing implementation for both setuptools and flit.

@pf_moore

Does this mean front ends must provide fine-grained control over config settings?

I don’t think so. It should be fair to assume backends will gracefully handle the behaviour in (1) and (2). With that in mind, I would say that if users want fine-grained control over how each package is built, they should perform separated frontend calls (one for each package).

---

1. There are a few use cases accross PyPA’s issue trackers implying that users expect to use a similar mechanism to influence the metadata (such as build tags added to the version). Examples: Wheel tags · Issue #202 · pypa/build · GitHub, https://github.com/pypa/setuptools/issues/2491. ↩︎