[Distutils] 400 Client Error: Binary wheel for an unsupported platform

[Nick Coghlan]

On 10 July 2015 at 00:50, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 9 Jul 2015 23:50:30 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>>
>> As Donald notes, I think we're now in a good position to start making
>> progress here, but the first step is going to be finding a way to
>> ensure that *by default*, pip on Linux ignores wheel files published
>> on PyPI, and requires that they be *whitelisted* in some fashion
>> (whether individually or categorically). That way, we know we're not
>> going to make the default user experience on Linux *worse* than the
>> status quo while we're still experimenting with how we want the
>> publication side of things to work. Debugging build time API
>> compatibility errors can be hard enough, debugging runtime A*B*I
>> compatibility errors is a nightmare even for seasoned support
>> engineers.
>
> By the way, I think there's another possibility if the Python packaging
> authority doesn't want to tackle this (admittedly delicate) problem:
> issue a public statement that Anaconda is the preferred way of
> installing Linux binary packages if they aren't provided (or the
> version is too old) by their Linux distribution of choice.

We already provide a page specifically aimed at alerting folks to
their prebuilt binary options for the scientific Python stack:
https://packaging.python.org/en/latest/science.html

In addition to referencing the upstream conda components, that also
links through to http://www.scipy.org/install.html where Anaconda and
Enthought Canopy are both mentioned. (Also Pyzo, which was a new one
to me, and further introduced me to a couple of interesting projects:
http://www.iep-project.org/index.html & its successor http://zoof.io/,
which aims to take advantage of the Project Jupyter architecture to
better support multiple language runtimes)

> It would then give more authority to software developers if they want
> to tell their users "don't use pip to install our code under Linux, use
> conda".

I'd personally phrase such suggestions more along the lines of "For
annoying technical reasons that folks are looking to find ways to fix,
if you don't want to build from source yourself, then you'll currently
need to use a Python redistributor rather than using the upstream
Python Package Index directly. We know the conda binaries are kept up
to date, but there isn't anyone we're aware of currently ensuring that
up to date versions of our packages are readily available through
Linux system package managers."

Along those lines, while it's my personal recommendation rather than
PyPA's collective recommendation, some of the references in
http://www.curiousefficiency.org/posts/2015/04/stop-supporting-python26.html
for "Third Party Supported" upgrade paths may prove useful.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia