And the conda folks are working on playing nice with virtualenv - I don't we'll see a similar offer from Microsoft for MSI any time soon :)
> > a single organisation. Pip (when used normally) communicates with PyPI
> > and no single organisation controls the content of PyPI.
>>For built distributions they could do
> > the same - except that pip/PyPI don't provide a mechanism for them to
> > do so.
Exactly, this is the difference between pip and conda - conda is a solution for installing from curated *collections* of packages. It's somewhat related to the tagging system people are speculating about for PyPI, but instead of being purely hypothetical, it already exists.
PyPI wheels would then be about publishing "default" versions of components, with the broadest compatibility, while conda would be a solution for getting access to alternate builds that may be faster, but require external shared dependencies.
What Christoph is doing is producing a cross-platform curated binary software stack, including external dependencies. That's precisely the problem I'm suggesting we *not* try to solve in the core tools any time soon, but instead support bootstrapping conda to solve the problem at a different layer.
So the pip compatible builds for those tools would likely miss out on some of the external acceleration features,
By ceding the "distribution of cross-platform curated software stacks with external binary dependencies" problem to conda, users would get a solution to that problem that they can use *now*,