Hi, On Mon, Apr 25, 2016 at 2:25 PM, Christian Aichinger <caichinger@ubimet.com> wrote:

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).

There's more discussion of this issue over on https://github.com/numpy/numpy/issues/7570 Cheers, Matthew

Hi, On Mon, Apr 25, 2016 at 2:25 PM, Christian Aichinger <caichinger@ubimet.com> wrote:

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).

There's more discussion of this issue over on https://github.com/numpy/numpy/issues/7570 Cheers, Matthew