Make --prefer-binary the default behavior for pip install

[geoffreyblake]

What's the problem this feature will solve?

Pip wheels with binary components are fast and easy to install and generally work out-of-the box vs downloading the source code and trying to build the wheel on the installing machine which may lack the toolchains needed (for some wheels they need more than a python-devel pkg and gcc). Pip currently prefers the latest packages even if it has to attempt building it.

Describe the solution you'd like

I'd like to see pip prefer downloading a binary wheel over source, so making --prefer-binary the default behavior instead of an optional flag.

Alternative Solutions

Using --prefer-binary on the command line works.

Additional context

Many wheels are built and released automatically by CI tool-chains and will do partial releases, this is a problem for some platforms like arm64 that will see wheels missing for some versions and then get fixed in a later release. Using a default --prefer-binary would skip a partial release instead of failing an install.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pradyunsg]

Hi, thanks for filing this suggestion.

While I do understand where you might be coming from, there's various reasons that changing the default to --prefer-binary is a non-trivial task that I don't think we'd be doing. The main one is that it's a somewhat disruptive backwards incompatible change -- there's definitely build pipelines that depend on this behavior, to function correctly. There are users who'd prefer the current behaviour of building a newer version of the package, since they have the relevant build infrastructure set up for it.

Many wheels are built and released automatically by CI tool-chains and will do partial releases, this is a problem for some platforms like arm64 that will see wheels missing for some versions and then get fixed in a later release. Using a default --prefer-binary would skip a partial release instead of failing an install.

This is better solved with staged releases on PyPI, something that's actually getting a bunch of volunteer effort put toward it right now -- pypi/warehouse#726 (comment)

[uranusjr]

Isn’t this basically #9140? That thread contains a lot more context and many proposals, including the one mentioned here.

[pfmoore]

Isn’t this basically #9140?

Yes, so I'm going to close this to centralise discussion on that issue.

[geoffreyblake]

Thanks, will instead watch those 2 issues more closely.