Prefering wheel-based installation over source-based installation

[pradyunsg]

@pfmoore said:
If we had a --prefer-binary option, that said "only use binaries, unless that means there are no candidates, in which case retry allowing source", I suspect many of my concerns that over-eager upgrading would result in breakage might be alleviated.

This issue serves as a starting point for further discussion on this proposed --prefer-binary flag.

[pradyunsg]

I agree. Binary (wheel-based) installations mostly "just-work". Plus, they are the preferred format for packaging and publishing to PyPI (at least from pip's point-of-view).

I think that making it the default would catalyse the adoption of wheels (not sure if it's needed though). Even in the long term, this seems to be a preferable.

[pradyunsg]

For completeness,

@dstufft said:
Likely bundled with a warning when that ends up not installing the latest version that would otherwise have been installed.

[pradyunsg]

I want to bother @dstufft and @pfmoore for this one. Thanks for keeping the discussions going.

Would you want to discuss this now or after the install-as-upgrade work is implemented?

---

From what I understand about the current situation,

• Some source installations require a C/C++/some-compiled-language compiler.
• Some source installations require extra configuration for proper building/installation of the package.
• Some source installations take a long time to complete.

While all this is fine and expected, the issue is pip does not know whether a source installation fits one of these, or any other case I missed.

Thus, source installations have to be treated differently from wheel installations. wheels are superior if it supports your platform. (Otherwise, it's only source builds. Those platforms won't be affected by this issue anyway) So, preferring them over source builds is indeed favourable. This is already the case for the selected (to-be-downloaded-and-installed) version.

However, there are situations when the user might be okay with getting a slightly older version of a package as long as it's a wheel, to simplify their life. The proposed --prefer-binary is a flag to provide this behaviour to the user.

[mmerickel]

Just a drive-by comment here: I have been bitten several times by projects uploading a new release and the wheels do not come for a little while later. This leaves the new sdist in a state where it is the default for pip. This can cause the build to fail until the wheel is finally uploaded.

Ideally --prefer-binary would be the default and if pip is not installing the latest version it can emit a warning. This only leaves cases where a project changed their build process such that they used to build pure-python wheels or wheels for a certain platform that they've now decided to stop building. The user could then use the warning to pin their package to foo > version-that-changed-build-process to avoid the binary logic falling back to that super old version.

[pradyunsg]

@mmerickel I don't think it should be default. Anyone installing a package would expect the latest version to be installed, unless they do something to the defaults (like passing this flag).

[kendallc]

Is there any update on this issue? This would be a useful feature help us avoid errors with missing C/C++ compilers and save installation time.

[pradyunsg]

Hi @kendallc!

Is there any update on this issue?

None yet. It's on my list but it's fairly low in it.

[akx]

This would be nice.

I have a case where I need to pre-download all dependencies for a package for fully offline installation on a different architecture; I can't specify the other architecture without specifying --only-binary=:all:, but that makes pip ignore source packages altogether, so not all packages get downloaded. I wouldn't like to have to sift through the list of dependencies (and transitive dependencies) to try and figure out which are binary and which aren't...

[drunkwcodes]

Considering this case (pypa/wheel#215), I think pip can't make the decision on the client side only.

Here is a plan for precedence logic of downloading format:

pip_options_specified or uploader_recommended or wheel_preferred

ref: pypi/warehouse#3106

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.