`--config-settings` recognizes only the last option

Description

The doc said:

The user can supply configuration settings using the --config-settings command line option (which can be supplied multiple times, in order to specify multiple settings).

If setting multiple times like this:

pip wheel --config-settings="--build-option=--cffi" --config-settings="--build-option=--avx2" -v .

Only the last option is passed to backend: {'--build-option': '--avx2'}

It seems these code let the last option override the previous options:

pip/src/pip/_internal/cli/cmdoptions.py

Lines 803 to 806 in c987c68

	if dest is None:
	dest = {}
	setattr(parser.values, option.dest, dest)
	dest[key] = val

Expected behavior

All options are passed to backend: {'--build-option': ['--cffi', '--avx2']}

Modify the code like this:

    if dest is None:
        dest = {key: []}
        setattr(parser.values, option.dest, dest)
    dest[key].append(val)

pip version

22.3.1

Python version

3.10

OS

Windows 11

How to Reproduce

1. define a custom PEP-517 hook get_requires_for_build_wheel
2. let the hook print the config_settings argument

    def get_requires_for_build_wheel(config_settings=None):
        print('config_settings argument:', config_settings)
        return []

Output

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct.

@pfmoore the author of the commit cdeb8f9

This command solves the problem.

pip wheel --config-settings="--build-option=--cffi --avx2" -v .

[layday]

I think there's a genuine bug here. Does your workaround work for all backends or does it just happen to work for setuptools because it's splitting (shlex.split) command-line arguments on its side? IOW, how does a command-line user construct a list of config setting values using pip?

I think there's a genuine bug here.

Yes, the behavior is different from the document, reopen the issue.

My workaround works for setuptools backend.

[pfmoore]

IOW, how does a command-line user construct a list of config setting values using pip?

Note the following in the config-settings documentation:

Build frontends SHOULD provide some mechanism for users to specify arbitrary string-key/string-value pairs to be placed in this dictionary.

Specifically, there's no requirement on frontends to provide a mechanism for users to specify anything other than a string value.

The pip example in the PEP is just an example of how pip might implement --config-settings, but it's not actually what we did. I'm not against the idea of allowing something like what is suggested here, but we need to be cautious. It's not pip's responsibility to define the semantics of config_settings, that's for backends, so what should happen is for backend maintainers to agree on what should be allowed as valid config settings, beyond the minimal "string key, string value" case defined by PEP 517. Once there's an agreed "extended standard", then pip can implement it.

For example, what if a user wants to pass a 1-element list to a backend? How would they do that? We can't mandate that backends have to treat a string value the same as a 1-element list containing that value. When I implemented the feature, I toyed with the idea of allowing JSON-encoded non-string values somehow. But supplying such values on the command line rapidly turns into a quoting nightmare, so I backed off and stuck with the minimum required by the standard.

Setuptools currently accepts lists by splitting. Maybe all backends should do that? I don't know, and it's not really my choice. It would be a lot simpler for frontends if that was the decision, of course.

Having said all of the above, I'm not necessarily against someone trying to implement something more complex. But if you do, be aware that any such behaviour will be very much pip-specific, and you can't assume that other frontends (such as build, or conda, or whatever) will behave the same, or indeed will go beyond the string value approach covered by the PEP which pip currently uses.

[layday]

My chief concern is that the homonymous option in build does behave differently. Somebody coming from pip to build, or from build to pip, as I assume has happened here, will find the discrepancy between the two tools surprising. I don't have a preference, but I think we shouldn't diverge without good reason. That could very well mean that build adopts pip's model for parsing config settings.

[pfmoore]

Good point. IMO, sticking with what's standardised is the correct approach here, which probably means string values only for now. If more complex values are important, then I think the standard needs updating to define the minimal set of types frontends should support. For instance, the build API is a Python API, so there's no reason a backend couldn't choose to interpret strings and numbers differently.

[rgommers]

We ran also into this issue in meson-python (xref mesonbuild/meson-python#235) and scipy (xref scipy/scipy#17736 (comment)). cibuildwheel ran into it too (xref pypa/cibuildwheel#1227 (comment)).

pypa/build allows using the same key more than once, and merges the result into a list of strings. It would be very useful for pip and pypa/build to have the same behavior here, and what pypa/build does seems reasonable, and I think also matches the intent of PEP 517 (given the example linked above does match).

Somebody coming from pip to build, or from build to pip, as I assume has happened here, will find the discrepancy between the two tools surprising.

+1 - also timely given the "unification of interfaces would be really nice" discussion happening on Discourse.

If more complex values are important, then I think the standard needs updating to define the minimal set of types frontends should support

I don't think there is anything in PEP 517 about this case either way, aside from the example which explicitly shows that "key1=value1" ... "key1=value2" gets merged into "key1" = ["value1", "value2"] when calling the build backend hook. So I'd suggest following that example. If you want a clarification in writing @pfmoore, where should it go? Writing a whole new PEP just to say "if keys are duplicate, merge them" seems a bit much.

[pfmoore]

Agreed, I'd be happy with a simple PR to change the spec. Unfortunately, it looks like no-one has migrated PEP 517 to https://packaging.python.org/en/latest/specifications/ yet, so it would have to be a PR changing the PEP itself (which is less than ideal, but what we've done in the past so I'm not bothered by it).

A quick post on discourse, asking if any backend would have a problem with frontends treating duplicated keys as a list of values, should be sufficient to confirm consensus. It might also be worth pointing out that this would mean that backends will never receive a single-element list for an option - instead, that would be passed as a non-list string argument. That's the thing I'm most concerned about (a backend saying "this option is always a list", and not expecting this quirk).

To be clear, I'm not expecting any arguments here, I just want to make sure we don't suddenly start sending unexpected config values to backends.