On Thu, Jan 14, 2016 at 9:14 AM, Chris Barker - NOAA Federal <chris.bar...@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 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
