You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
PEP 517 provides the option for build frontends to pass a config_settings argument to build hooks. This is intended to be a dictionary of backend-specific options and their values. Currently, few if any backends support config settings, so pip has not needed to support this argument.
If and when backends start to offer configuration options via config_settings, users will want to be able to supply them from pip.
Describe the solution you'd like
I don't have a good intuition for what the UI for config settings would look like. I could imagine that we might need any or all of the following:
Per project settings (set option1=12, option2=true for project FOO).
Per backend settings (set xxx=something for all calls to flit).
Per hook settings (set xxx=something for build_wheel calls).
Or any combination of these. Without knowing what sorts of things backends might want to do it's hard to know what possibilities are reasonable to support. But if we make things too general, the UI will be over complex.
Alternative Solutions
I'm thinking of prototyping a backend which uses config options. If I do so, I will probably start by having a single pip option that points to a file containing some form of specification of options - quite likely in TOML format. That would offer a "quick and dirty" solution.
It's possible that would even be sufficient for general use, although having to write and reference a separate file might be annoying for users.
Additional context
This is the PEP 517 equivalent of the legacy --install-option argument. Maybe some insights could be taken from how that worked (although IMO the interface for that option was pretty clumsy).
One practical use for config settings may be build backends that want to allow the user to choose from multiple strategies for implementing editable installs.
Note that there is no urgency for this feature - until there are backends that use config settings it adds no value. However, I think it's useful to have this as a master issue to collect design discussions and use cases.
What's the problem this feature will solve?
PEP 517 provides the option for build frontends to pass a
config_settings
argument to build hooks. This is intended to be a dictionary of backend-specific options and their values. Currently, few if any backends support config settings, so pip has not needed to support this argument.If and when backends start to offer configuration options via
config_settings
, users will want to be able to supply them from pip.Describe the solution you'd like
I don't have a good intuition for what the UI for config settings would look like. I could imagine that we might need any or all of the following:
Or any combination of these. Without knowing what sorts of things backends might want to do it's hard to know what possibilities are reasonable to support. But if we make things too general, the UI will be over complex.
Alternative Solutions
I'm thinking of prototyping a backend which uses config options. If I do so, I will probably start by having a single pip option that points to a file containing some form of specification of options - quite likely in TOML format. That would offer a "quick and dirty" solution.
It's possible that would even be sufficient for general use, although having to write and reference a separate file might be annoying for users.
Additional context
This is the PEP 517 equivalent of the legacy
--install-option
argument. Maybe some insights could be taken from how that worked (although IMO the interface for that option was pretty clumsy).The PEP 517 section on config settings.
One practical use for config settings may be build backends that want to allow the user to choose from multiple strategies for implementing editable installs.
Note that there is no urgency for this feature - until there are backends that use config settings it adds no value. However, I think it's useful to have this as a master issue to collect design discussions and use cases.
Code of Conduct
The text was updated successfully, but these errors were encountered: