pip not naming abi3 wheels correctly

[alex]

Environment

• pip version: 19.0.3
• Python version: 3.x
• OS: macOS and Linux

Description
Attempting to build an abi3 wheel, on macOS or Linux, is not actually producing an abi3 one:

~/.v/tempenv-22383155163ae ❯❯❯ env                        CRYPTOGRAPHY_SUPPRESS_LINK_FLAGS="1" \
                                                           LDFLAGS="/usr/local/opt/openssl@1.1/lib/libcrypto.a /usr/local/opt/openssl@1.1/lib/libssl.a" \
                                                           CFLAGS="-I/usr/local/opt/openssl@1.1/include -mmacosx-version-min=10.9" \
                               pip wheel cryptography==2.6 --wheel-dir=wheelhouse --no-binary cryptography --no-deps --build-option --py-limited-api=cp34
/Users/agaynor/.virtualenvs/tempenv-22383155163ae/lib/python3.7/site-packages/pip/_internal/commands/wheel.py:109: UserWarning: Disabling all use of wheels due to the use of --build-options / --global-options / --install-options.
  cmdoptions.check_install_build_global(options)
Collecting cryptography==2.6
  Using cached https://files.pythonhosted.org/packages/a3/5f/d5b7d21006e3c1a3919a3cc14e2a5ce1cee1c7ff635f09b31d91bdaff377/cryptography-2.6.tar.gz
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Building wheels for collected packages: cryptography
  Building wheel for cryptography (PEP 517) ... done
  Stored in directory: /Users/agaynor/.virtualenvs/tempenv-22383155163ae/wheelhouse
Successfully built cryptography

Expected behavior
There'll be an abi3 wheel in the wheelhouse.

Output

Instead there is a normal, non-abi3, wheel.

~/.v/tempenv-22383155163ae ❯❯❯ ls wheelhouse/
cryptography-2.6-cp37-cp37m-macosx_10_14_x86_64.whl

[pfmoore]

Pip's PEP 517 build support does not support --build-options. The problem here is that --build-options is a setuptools/wheel specific flag, and there's no general equivalent in PEP 517. There is the config_settings dictionary, but we don't (currently) have a way of mapping pip settings to that (at least not in a way that avoids sending setuptools config to flit, for example).

Suggestions for how to handle this in a general way would be gratefully accepted (as would PRs ;-))

--no-use-pep517 is probably the best approach for now.

[alex]

Ok. It would have been very helpful to us if this had error'd loudly, instead of silently ignoring it. I agree that simply disabling pep517 in our wheel builder is probably the way to go. Thank you.

[tiran]

• python3-pip-18.1-1.fc29.noarch, python3-setuptools-40.4.3-1.fc29.noarch, python3-wheel-0.31.1-3.fc29.noarch I'm getting cryptography-2.6.dev1-cp34-abi3-linux_x86_64.whl
• pip 19.0.3, setuptools 40.8.0, wheel 0.33.1 are creating cryptography-2.6.dev1-cp37-cp37m-linux_x86_64.whl

[pfmoore]

It would have been very helpful to us if this had error'd loudly

Agreed. When I wrote the code, I skipped build_options when I realised it didn't fit well with the PEP 517 spec, but I forgot to go back and add a proper error/warning for the situation.

[cjerdonek]

What would be best for pip to do here — terminate with an error or log a warning?

[alex]

Error loudly please. We (pyca, as well as projects we build wheels for, such as cffi) build wheels in automation, so we probably wouldn't have noticed a warning.

[pfmoore]

I've created #6305 as an initial attempt at this.

[cjerdonek]

By the way, I noticed these lines in the original post for this issue:

UserWarning: Disabling all use of wheels due to the use of --build-options / --global-options / --install-options.
cmdoptions.check_install_build_global(options)

But for the wheel command the build_options are passed:

pip/src/pip/_internal/commands/wheel.py

Lines 166 to 171 in 62cfaf0

	# build wheels
	wb = WheelBuilder(
	finder, preparer, wheel_cache,
	build_options=options.build_options or [],
	global_options=options.global_options or [],
	no_clean=options.no_clean,

and used in the legacy case:

pip/src/pip/_internal/wheel.py

Lines 943 to 947 in 62cfaf0

	spin_message = 'Building wheel for %s (setup.py)' % (req.name,)
	with open_spinner(spin_message) as spinner:
	logger.debug('Destination directory: %s', tempd)
	wheel_args = base_args + ['bdist_wheel', '-d', tempd] \
	+ self.build_options

Does this mean that warning is no longer correct in this case? Here is the commit where that warning was introduced (with associated issue #2677): 0d2cc68

[pfmoore]

I noticed this. I honestly have no idea what it's reasonable to expect when using --build-options with PEP 517, or even with a build-wheel-then-install-it process.

This is another area where I think we should simplify pip's command line options, and just drop --build-option (and the related --install-option and --global-option). While we have a mix of PEP 517 and legacy processing, there simply isn't a reliable way for the user to know what to specify. I know we'll cause problems for people with a need for that much control by doing so, but I don't honestly see how there's a better solution right now (--no-use-pep517 is at best a temporary stopgap).

Once we've dropped the legacy code path, and everything is going via PEP 517, we can rely on the standard config_options dictionary, and introduce a command line syntax for specifying that.

[pfmoore]

#6305 merged.

[njsmith]

The intention of config_options was that pip could pick some way to encode legacy options like this, and we'd teach setuptools to understand it. This does mean you could pass setuptools options to flit. But, since the whole point of the config_options interface is that it's random non-standard stuff that pip doesn't understand, there's no way for pip to avoid that even in principle, and flit can say "sorry, I don't understand that option" if it wants.

[cjerdonek]

A couple separate things:

First, I looked at the corresponding pip install code, and it looks like the build_options are silently dropped, even in the "no PEP 517" case:

pip/src/pip/_internal/commands/install.py

Lines 338 to 341 in c9df690

	wb = WheelBuilder(
	finder, preparer, wheel_cache,
	build_options=[], global_options=[],
	)

Is this a similar issue that needs to be resolved in the short term?

Second, @njsmith, are you saying you think there might be a better change for the short-term with respect to this issue, or was your comment more about the long-term? Regarding the long-term, do you think you could file issues to reflect your understanding of what you think needs to be done for the future (e.g. setuptools and/or pip issues)?

[reaperhulk]

In PyCA's particular case we only use --build-option to pass the flag to build abi3 wheels. If pip wheel had explicit support for that (e.g. pip wheel --py-limited-api=cp34) we, and probably others, could stop using the --build-option escape hatch. This seems like a flag that pip might want to consider adding given the importance of abi3 wheels to the ecosystem, but I also understand a desire to avoid proliferation of flags.

[njsmith]

@reaperhulk the problem isn't that pip is missing a flag, it's that the abstract API that pip uses to invoke the build backend internally (PEP 517) has no abstract way to say "build abi3 wheels". So even if pip had a flag for this, it doesn't have any way to pass that on to the build backend.

[reaperhulk]

Thanks for the clarification Nathaniel. Having build backends that don’t understand concepts like this seems...non-ideal, but is outside the scope of a pip bug 😄

[pfmoore]

@reaperhulk Part of the problem here is that some backends (such as flit) don't support C extensions at all, so there's no common ground here.

Just expanding on @njsmith's comments, things for consideration in the longer term:

1. Pip cannot do anything other than pass a generic config_dict unless backends agree on a standard for particular config options. Such a standard would need to be a PEP, building on PEP 517.
2. At the moment there isn't even a standard that says that backends should (must) ignore config parameters that they don't understand. Maybe that should be an addition to PEP 517?
3. Pip's current --build-option style flags are typically set per invocation (they can be per-requirement in a requirements file) so it's clumsy to set config that only applies to certain projects (say, those that build with flit). This should be addressed, even if (2) gets dealt with, as there's nothing preventing two different backends from assigning completely different behaviours to the same config element.

Note that it's easy to overlook a lot of the complexity, because we currently live in a world with only two common backends, setuptools and flit - and flit is still very much a newcomer, and doesn't handle C compilation. But we need to look at the longer term, and assume new backends will be developed and become popular. We really don't want to end up building a PEP 517 infrastructure around a whole new set of setuptools-specific assumptions, that's precisely the trap that PEP 517 was intended to get us out of.

[asottile]

when working with setup.py I've found a workaround at least:

• Build abi3 wheels asottile/onigurumacffi#3
• Build abi3 wheels with latest pip hynek/argon2-cffi#57

[th0ma7]

Looking at the issue I feel I'm in a loophole, on one hand I need to disable PEP517 to get abi3 limited... on the other cryptography mandatory needs PEP517 for building. What options are left besides downgrading or moving out from pip?

[alex]

Using setup.py directly instead of pip was our solution to the problem. If you find a better one, let us know.

…

On Mon, Oct 3, 2022 at 7:56 PM Vincent Fortier ***@***.***> wrote: Looking at the issue I feel I'm in a loophole, on one hand I need to disable PEP517 to get abi3 limited... on the other cryptography mandatory needs PEP517 for building. What options are left besides downgrading or moving out from pip? — Reply to this email directly, view it on GitHub <#6304 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBCITG3UFHKAEXUHRD3WBNXELANCNFSM4G2TK3HA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[pfmoore]

Pip now has a --config-options flag. If setuptools has a way to request this behaviour via config options, that might be a way forward.

[alex]

I believe the pip-side of this work is complete, so I'm going to close this.

To future people reading: it's not clear to me whether setuptools actually uses the config-settings data anywhere, but pypa/setuptools#3896 is the right place for that discussion.