On Fri, Jan 15, 2016 at 11:56 AM, Travis Oliphant <tra...@continuum.io> wrote: > [...] > I still submit that this is not the best use of time. Conda *already* > solves the problem. My sadness is that people keep working to create an > ultimately inferior solution rather than just help make a better solution > more accessible. People mistakenly believe that wheels and conda > packages are equivalent. They are not. If they were we would not have > created conda. We could not do what was necessary with wheels and > contorting wheels to become conda packages was and still is a lot more work. > Now, obviously, it's just code and you can certainly spend effort and time > to migrate wheels so that they functionally equivalently to conda packages > --- but what is the point, really?
Sure, conda definitely solves problems that wheels don't. And I recommend Anaconda to people all the time :-) But let me comment specifically on the topic of numpy-and-pip. (I don't want to be all "this is off-topic!" because there isn't really a better list of general scientific-python-ecosystem discussion, but the part of the conda-and-pip discussion that actually impacts on numpy development, or where the numpy maintainers can affect anything, is very small, and this is numpy-discussion, so...) Last month, numpy had ~740,000 downloads from PyPI, and there are probably hundreds of third-party projects that distribute via PyPI and depend on numpy. So concretely our options as a project are: 1) drop support for pip/PyPI and abandon those users 2) continue to support those users fairly poorly, and at substantial ongoing cost 3) spend some resources now to make pip/pypi work better, so we can support them better and at lower ongoing cost Option 1 would require overwhelming consensus of the community, which for better or worse is presumably not going to happen while substantial portions of that community are still using pip/PyPI. If folks interested in pushing things forward can convince them to switch to conda instead then the calculation changes, but that's just not the kind of thing that numpy-the-project can do or not do. So between the possible options, I've been spending some time trying to drag pip/PyPI into working better for us because I like (3) better than (2). It's not a referendum on anything else. I assume that others have similar motives, though I won't try speaking for them. I think beyond that there are also (currently) some unique benefits to supporting pip/PyPI, like the social/political benefits of not forking away from the broader Python community, and the fact that pip is currently the only functioning way we have of distributing numpy prereleases to users for testing. (The fine-grained numpy ABI tracking in conda is neat, but for this particular use case it's actually a bit of a problem :-).) But it doesn't much matter either way, because we can't/won't just abandon all those users regardless. -n -- Nathaniel J. Smith -- http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion