<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 9, 2015 at 3:41 PM, Chris Barker <span dir="ltr"><<a href="mailto:chris.barker@noaa.gov" target="_blank">chris.barker@noaa.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>pip is a special case -- for MOST python command line tools, the user does not care which python it is running with -- if it works, it works.</div><div><br></div><div>the failure case we are trying to address here is when "pip install" works sjtu fine -- it finds and installs the package into the python pip is associated with -- it just doesn't do what the user wants and expects!<br></div></div></div></div></blockquote><div><br></div><div>I still feel like it's just kicking the problem down the line. Switching from 'pip install' to 'python -m pip install' doesn't actually solve the issue of how easy we've made it for people to create non-functional Python installations (non-functional in the sense that they will mysteriously "work but not really work"). All this switch does is hand the problem over to the *next* tool the user happens to invoke. So "pip is special" doesn't really work as a rebuttal, at least to me.<br></div><div><br></div><div>The real problem to solve is management of multi-Python installations; I don't really know right now *how* to solve it, but slapping one band-aid onto the problem by changing pip won't accomplish that and so will break a lot of existing conventions and documentation for what seems like at best very minor gains.</div></div></div></div>