On Fri, May 27, 2022 at 6:00 AM Aaron Meurer <asmeurer@gmail.com> wrote:
On Thu, May 26, 2022 at 3:45 AM Matti Picus <matti.picus@gmail.com> wrote:
On 26/5/22 05:40, Aaron Meurer wrote:
We cannot do that (yet, at least). Failing to publish wheels for a supported Python version on a major OS is far worse than dropping support completely. This will remain true until the time that Pip starts defaulting to wheels-only and never picks the sdist if there's an older release for that platform + Python combo. sounds like if even the latest version doesn't support a given CPython version (and has CPython-versioned wheels), then pip installing it will fail. Is that correct?
No. The problem is that if we do not provide binary wheels, pip installing Numpy will not fail. It will try to build from source. Even if this painfully and slowly succeeds, it means the user probably did not get the BLAS support they thought they were going to get. The situation for SciPy is similar but worse: it takes forever to build, and will probably likewise fail to build properly.
If Python version 3.X isn't supported, and that non-support means it actually doesn't work, then it will fail. That is unless pip is smart enough to install the most recent version of NumPy that does support that version of Python (which would have wheels). Ralf made it sound like this is what would happen, but doesn't pip have python_requires to avoid this?
There's several issues, not sure which one you are asking about, so let me address all the options: 1. The release/sdist supports a Python release, but we have no wheels for it. Then, Pip's default behaviour is to build from source (sdist). This is highly likely to fail, because we have dependencies like compilers and a BLAS library that cannot even be expressed in metadata. We do not want `pip install numpy` to trigger building from source for the most commonly used platforms (Windows, macOS, Linux on x86-64/aarch64 at least), because that would lead to a flood of "build is broken" issues. 2. If there's a new Python release for which we don't yet have wheels or an sdist to support that, Pip will grab the last sdist that doesn't say python_requires='>=3.xx,<3.yy' (i.e., that doesn't have an upper bound). That will definitely fail. We can't really do anything about that other than raising a more informative error message at the start of the build. 3. Tools like Pip and Poetry do not handle python_requires correctly unfortunately. Long story, don't want to get into it, but let's just say it doesn't work as you'd expect from install_requires. Long story short: we do everything we can to get our metadata correct and have wheels for the most commonly used OSes and platforms, and *all* supported Python versions in a release. Any proposal that drops wheel coverage for Python version support is not realistic. Cheers, Ralf