On 2 November 2016 at 03:01, Chris Barker <chris.bar...@noaa.gov> wrote: > Nick missed the key point about conda. He mentioned that conda allows you to > manage the python run-time itself, which is in deed a nice feature, but > getting a python run-time as never been the hard part (maybe on Linux if you > want a different one than your system supplies).
I didn't miss it accidentally, I left it out because it wasn't relevant to the post (which was about the ecosystem design direction, not the end user features that make the desire to use pip incomprehensible to a lot of folks). Designing software assembly tools for interpreted software is a system integrator's game, and when people are writing Python code, there is one absolutely 100% unavoidable integration task: choosing which Python runtimes they're going to support. But as an ecosystem designer, even if you only consider that single core integration activity, you have already hit a fundamental difference between pip and conda: conda requires that you use a runtime that it provides (similar to the way Linux distro packaging works), while pip really doesn't care where the runtime came from, as long as it can run pip properly. Essentially all the other differences between the two systems stem from the different choice made in that core design decision, which is why the two aren't substitutes for each other and never will be - they solve different problems for different audiences. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
