Re: [Numpy-discussion] Adding the Linux Wheels for old releases breaks builds

[Matthew Brett]

Hi,

On Mon, Apr 25, 2016 at 2:25 PM, Christian Aichinger
 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 .
>
> 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
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] Adding the Linux Wheels for old releases breaks builds

[Christian Aichinger]

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 .

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 
caichin...@ubimet.com • www.ubimet.com
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion