PEP 660 and setuptools

[pf_moore (Paul Moore)]

@pf_moore

At the moment, pip’s support for config_settings is weak, but we could easily improve this. The current expectation is that the form would be something like --config-settings KEY=VALUE . I am personally willing to take on the work to implement this.

I’m currently looking at how to implement this. The implementation shouldn’t be too tricky, but there are a bunch of design-level and policy questions around config_settings that need to be considered. I can simply make expedient choices to make things easier for pip to implement, and that’s likely what I’ll do in the absence of a wider consensus, but at some point we need to reach some decisions.

1. Is config_settings supposed to be constant across all hook calls? See this thread for more detail.
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.
3. PEP 517 states “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”. Does this mean front ends must provide fine-grained control over config settings^[1] (this contradicts the suggested syntax in the PEP)? If so, is doing so at the cost of user friendliness an acceptable trade-off? If not, again are backends expected to be forgiving of settings “leaking through”?

My personal answers to these questions, from a “what is expedient for pip” perspective, are:

1. The frontend will only guarantee to pass the specified settings to the relevant build_XXX calls.
2. The frontend won’t make any particular effort to avoid passing settings to backends (or hooks) that might not expect them.
3. Pip will allow KEY=VALUE settings that apply to every package in the run, or on a per-package basis, but the latter only if specified in a requirements file.
4. As a consequence, backends should be prepared to silently ignore anything they don’t expect/want to handle^[2].

None of these are set in stone, they are just “what I’ll go with in the absence of anyone saying they need something different”. If any of them would cause problems, please speak up. But I’d rather focus on practical concerns over how to make pip’s support useful (with particular emphasis on setuptools’ editable install support) rather than on broad theoretical debates over what people “might” choose to use config settings for in some as-yet nonexistent backend…

---

1. The extreme case here would be settings that explicitly specify package, backend, hook, name and value. ↩︎

2. It may be that they already do that, in which case simply saying so publicly might be enough to deal with a lot of the risk here. ↩︎