[Distutils] Handling the binary dependency management problem

[Oscar Benjamin]

On 3 December 2013 21:13, Donald Stufft <donald at stufft.io> wrote:
> I think Wheels are the way forward for Python dependencies. Perhaps not for
> things like fortran. I hope that the scientific community can start
> publishing wheels at least in addition too.

The Fortran issue is not that complicated. Very few packages are
affected by it. It can easily be fixed with some kind of compatibility
tag that can be used by the small number of affected packages.

> I don't believe that Conda will gain the mindshare that pip has outside of
> the scientific community so I hope we don't end up with two systems that
> can't interoperate.

Maybe conda won't gain mindshare outside the scientific community but
wheel really needs to gain mindshare *within* the scientific
community. The root of all this is numpy. It is the biggest dependency
on PyPI, is hard to build well, and has the Fortran ABI issue. It is
used by very many people who wouldn't consider themselves part of the
"scientific community". For example matplotlib depends on it. The PyPy
devs have decided that it's so crucial to the success of PyPy that
numpy's basically being rewritten in their stdlib (along with the C
API).

A few times I've seen Paul Moore refer to numpy as the "litmus test"
for wheels. I actually think that it's more important than that. If
wheels are going to fly then there *needs* to be wheels for numpy. As
long as there isn't a wheel for numpy then there will be lots of
people looking for a non-pip/PyPI solution to their needs.

One way of getting the scientific community more on board here would
be to offer them some tangible advantages. So rather than saying "oh
well scientific use is a special case so they should just use conda or
something", the message should be "the wheel system provides solutions
to many long-standing problems and is even better than conda in (at
least) some ways because it cleanly solves the Fortran ABI issue for
example".


Oscar