On Nov 2, 2016, at 7:08 PM, Chris Barker <chris.barker@noaa.gov> wrote:

perhaps so -- but it will be a good while! The endorsement of the "official" community really does keep pip going. And, of course, it works great for a lot of use-cases.

Right, there is some overlap in terms of “I am on Windows/macOS/most Linuxs and I either prefer Anaconda for my Python or I don’t care where it comes from and I don’t have any compelling reasons NOT to use something different”. That can be a pretty big chunk of people, but then there is an area that doesn’t overlap that the differences in decisions aren’t really going to be very easy to reconcile.

For instance, the obvious one that favors conda is anytime your existing platform isn’t providing you something that conda is providing (e.g. a new enough NumPy on CentOS, or binary packages at all on Windows, or what have you).

The flip side of that is pip’s ability to just-in-time build binary packages means that if you’re deploying to say, alpine linux like a lot of the folks using Docker is doing or to FreeBSD or something like that then, as long as your system is configured, `pip install` will just work without you having to go through the work to stand up an entire Conda repository that contains all of the “bare minimum” compiled packages for an entire new architecture. Pip’s ability to “slot” into an existing environment also means that it generally just works in any environment you give it, if you want something that will integrate with something installed by apt-get, well you’re going to have a hard time getting that with conda.

Beyond all of that though, there’s more to the pip tooling than just what command line program some end user happens to be executing. Part of this is enabling a project author to release a package that can be consumed by Conda and Debian and RHEL and Alpine and FreeBsd ports and etc etc. I don’t mean in the sense of “I can run ``pip install`` on them, but in the sense that by the very nature of our JIT building from source we need a programmatic standard interface to the build system, so if pip can automatically consume your package then conda-build and such becomes much easier to write for any individual package.

At the end of the day, sure it would make some things a bit easier if everyone would just standardize around one thing, but I doubt it will ever happen because these things really do serve different audiences once you leave the overlap. Much like it’d be great if everyone just standardized on Ubuntu! Or Debian! Or CentOS! Or macOS! Or Windows! Or it’d be nice if everyone picked a single Python version, or a single Python implementation, or a single language at all :) So yea, diversity makes things more difficult, but it also tends to lead to better software overall :D

If it were all up to me (which of course it's not) -- I'd say that keeping pip / PyPi fully supported for all the stuff it's good at -- pure python and small/no dependency extension modules -- and folks can go to conda when/if they need more.

After all, you can use pip from within a conda environment just fine :-)

I think this is pretty much where we're at and where we’re likely to stay for the general case as far as what is officially supported. We may gain some stuff to try and integrate better with whatever platform we’re on (for instance, the metadata that Nick suggested that would allow people to say “I need libgd” and have conda or apt or whatever provide that) but I don’t think we’re likely to go much further than that.

I know that there is the pynativelib stuff which would cross into that threshold, but one of the things about that proposal is it doesn’t require anything from pip or PyPI or whatever to make it happen. That’s “just” some square pegging into a round hole to sort of try and close the gap a little bit but I doubt it’s ever going to be something that even approaches a solution like what Conda/apt/etc give.