In short: on posix: pyenv, pipx, then virtualenv+pip or conda. Pyenv: tool to manage different python major/minor/patch versions. Pipx: installs CLI/GUI tools

In short: on posix: pyenv, pipx, then virtualenv+pip or conda. Pyenv: tool to manage different python major/minor/patch versions. Pipx: installs CLI/GUI tools in their own virtualenv and links them to ~/.local/bin. Way more convenient if you have commonly used tools virtualenv: use to isolate python environments Pip: used to install packages Conda: basically does all the above, also handles linked libraries and a bunch of stuff. Annoying for deployment, but it's often the least worst option. Python-N.M: use pyenv to manage your python installations. Way cleaner than brew. Never use system python for things. Python2 thru 3.3: you really ought to be using py>3.6 by now, but it may not be your choice. I haven't in years but I think you can use pipx or "pip install --user virtualenv" to get the virtualenv binary. Then use virtualenv from there. Py>3.3: use "python -m venv" to manage virtualenvs. Use pipx to install cli tools. Do everything in venvs. On windows or if you rely on lots of academic packages: you are probably better off just using conda. Also the pre-commit tool manages its own virtualenv cache, which is cool for making repos easy to bootstrap. There's also poetry, but it's more new and if you are at the point in your python journey that you are asking these questions, then in my opinion it's likely to just muddy the waters more. And if anyone is curious "why the hell is python this way? I don't have this problem with $LANGUAGE?" It's because when python fires up, basically a small miracle occurs that is able to locate and execute .py, .pyc, .zip, several other file types, directories, compiled libraries, and basically anything you want if you override the module machinery.