Hi! The addition of the Linux Wheels broke the build process of several of our Debian packages, which rely on NumPy installed inside virtualenvs. The problem stems from the pre-compiled shared libraries included in the Wheels, details are in https://github.com/numpy/numpy/issues/7570. I'm bringing this up here because these changes have implications that may not have been fully realized before. The Wheel packages are great for end users, they make NumPy much more easily installable for average people. Unfortunately, they are precisely the wrong thing for anyone re-packaging NumPy (e.g. shipping it in a virtualenv inside RPM or Debian packages). For that use-case, you typically want to build NumPy yourself.[1] You could rely on this happening before, now a `--no-binary` argument for pip is needed to get that behavior. Put another way, the addition of the Wheels silently invalidated the assumption that a `pip install numpy` would locally compile the package. In the perfect world, anyone re-packaging NumPy would specify `--no-binary` if they want to enforce local building. However, currently, --no-binary is not in widespread use because it was never necessary before. I fully agree that the Wheels have great value, but adding them for old releases (back to 1.6.0 from 2011) suddenly changes the NumPy distribution for people who explicitly pinned an older version to avoid surprises. It invites downstream build failures (as happened to us) and adds externally-built shared objects in a way that people won't expect. I would propose to only add Wheels for new releases and to explicitly mention this issue in the release notes, so people are not blind-sided by it. I realize that this would be a painfully slow process, but silently breaking previously working use-cases for old releases seems worse to me (though it is difficult to estimate how many people are negatively affected by this). Regards, Chris [1]: You want to build locally for many reasons, e.g. to link against your system's libraries which you get security upgrades for; to have the confidence that you can actually build the package from source if need be; to be sure that the binaries really correspond to the source code; ... ------------------------------------------------------------------------------------------------------------------- UBIMET GmbH - weather matters Christian Aichinger • IT A-1220 Wien • Donau-City-Straße 11 • Tel +43 1 263 11 22 • Fax +43 1 263 11 22 219 caichinger@ubimet.com • www.ubimet.com