[Distutils] Handling the binary dependency management problem

[Paul Moore]

On 1 December 2013 19:21, Marcus Smith <qwcode at gmail.com> wrote:
>>> sometimes mean needing to build components with external dependencies
>>> from source
>
> you mean build once (or maybe after system updates for wheels with external
> binary deps), and cache as a local wheel, right?

Note that it is possible to convert binary packages from other formats
to wheel. We already support egg and bdist_wininst. If conda has built
packages that are worth supporting, I doubt that a conda-to-wheel
converter would be hard to write. I'd be willing to write one if
someone can point me at a spec for the conda package format (I
couldn't find one from a brief look through the docs).

Conversely, if I have a wininst installer, a wheel or an egg, is there
a converter to conda format? I can't see having to use conda for some
things and pip for others as being a move towards lessening user
confusion.

I see conda (and enthought) as more like distributions - they sit in
the same space as rpms and debs. I don't see them as alternatives to
pip. Am I wrong? After all, both conda and enthought supply Python
interpreter builds as well as package repositories. And both feel like
unified ecosystems (you manage everything Python-related with conda)
rather than tools like pip (that works with existing Python standards
and interoperates with easy_install, distutils, etc).

If the issue is simply around defining compatibility tags that better
describe the various environments around, then let's just get on with
that - we're going to have to do it in the end anyway, why temporarily
promote an alternative solution just to change our recommendation
later?

Paul