On Thu, Jan 14, 2016 at 9:14 AM, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:
Also, you have the problem that there is one PyPi -- so where do you put your nifty wheels that depend on other binary wheels? you may need to fork every package you want to build :-(
Is this a real problem or a theoretical one? Do you know of some situation where this wheel to wheel dependency will occur that won't just be solved in some other way?
It's real -- at least during the whole bootstrapping period. Say I build a nifty hdf5 binary wheel -- I could probably just grab the name "libhdf5" on PyPI. So far so good. But the goal here would be to have netcdf and pytables and GDAL and who knows what else then link against that wheel. But those projects are all supported be different people, that all have their own distribution strategy. So where do I put binary wheels of each of those projects that depend on my libhdf5 wheel? _maybe_ I would put it out there, and it would all grow organically, but neither the culture nor the tooling support that approach now, so I'm not very confident you could gather adoption.
I don't think there's a very large amount of cultural work - but some to be sure. We already have the following on OSX: pip install numpy scipy matplotlib scikit-learn scikit-image pandas h5py where all the wheels come from pypi. So, I don't think this is really outside our range, even if the problem is a little more difficult for Linux.
Even beyond the adoption period, sometimes you need to do stuff in more than one way -- look at the proliferation of channels on Anaconda.org.
This is more likely to work if there is a good infrastructure for third parties to build and distribute the binaries -- e.g. Anaconda.org.
I thought that Anaconda.org allows pypi channels as well? Matthew