Why to use ‘python -m pip’

To prevent accidentally installing in the global interpreter I have this in my .bash_profile:<p><pre><code> # pip should only run if there is a # virtualenv currently activated export PIP_REQUIRE_VIRTUALENV=true</code></pre>

&gt;Now you may be saying, &quot;I always install the latest versions, so that would mean Python 3.8.0 was installed last since it&#x27;s newer than 3.7.5&quot;. OK, but what happens when Python 3.7.6 comes out? Your pip command would have gone from using Python 3.8 to Python 3.7.<p>This seems less like a reason to use `python -m pip` and more a reason to endorse languages with saner versioning and less need to sandbox twenty different versions from one another.

Just use [mini]conda. Everytime someone posts about a python package issue or virtual env issue, it&#x27;s something that conda already had solved before 2014. And yes, pip is fully supported within a conda environment.<p>I really can&#x27;t figure out why conda is not ore popular.

Pip is a powerful but low-level tool, which probably shouldn&#x27;t be user-facing. It doesn&#x27;t have a full resolver, locking mechanism, or environment management. Likewise setuptools.<p>For installing global command-line scripts, I like pipx instead of pip. <a href="https:&#x2F;&#x2F;github.com&#x2F;pipxproject&#x2F;pipx" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pipxproject&#x2F;pipx</a><p>For development, I like Poetry instead of pip. <a href="https:&#x2F;&#x2F;poetry.eustace.io" rel="nofollow">https:&#x2F;&#x2F;poetry.eustace.io</a>

&gt; “Let&#x27;s say I have two versions of Python installed, like Python 3.7 and 3.8 (and this is very common for people thanks to Python coming installed on macOS and Linux, let alone you may have installed Python 3.8 to play with it while having previously installed Python 3.7). Now, if you were to type pip in your terminal, which Python interpreter would it install for?”<p>Yeah but you just kick the can to which python happens to be the system python or activated python referenced by “python”. It’s exactly the same problem.<p>If I as a user have to be careful of which underlying Python installation is being referenced, then I want to be responsible for activating the conda environment I need and using “regular” commands like plain “pip” after that. The “python -m” idiom is not important for this use case, as it doesn’t actually solve the problem (ensuring the right referenced Python).

if you use a per project venv I see no reason not to use `pip install`. if you don&#x27;t use a per project venv, well, do that!

Maybe it&#x27;s just on my installation, but pip comes with versioned executables. That is, I can call &quot;pip3.7&quot; or &quot;pip3.4&quot;. What&#x27;s the benefits of using the -m approach in this case?

Pip is so bad vs rivals, conda is so much better I&#x27;m amazed it&#x27;s not the recommended package manager.

<p><pre><code> alias pip python -m pip </code></pre> then stop worrying about it

As someone who is stuck on a very old version of python (2.7) on win32 due to Reasons (vendors, basically), how I wish I could even try to install pip; unfortunately, it will only recommend upgrading to a newer version of python when I attempt. All roads seem to lead to this place, a one-size-fits-all dismissive &quot;lol upgrade.&quot;<p>Packaging is one of my least favorite things about the language I love the most.

This kind of stuff is my least favorite attribute of Python. Surely there must be a better way?

&quot;that&#x27;s why you should use virtualenv&quot;

TL;DR because Python is a mess, and installations are often messed up.

Okay, or just use pipenv.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;pipenv" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;pypa&#x2F;pipenv</a>

I usually use pip3 install --user. Then just add ~&#x2F;.local&#x2F;bin to PATH. It hasn&#x27;t caused any issues for me thus far. I also use venv, but only in CI to make sure that other people&#x27;s environments don&#x27;t get messed up. I personally prefer using pip3 install --user.