Python virtualenv wrapper fns - virtualenv vs venv about dotfiles HOT 3 OPEN

More points to note:

• venv is only available in Python 3.5+, so if a project must use Python < 3.5, it must use virtualenv
• venv has mixed reception, though it appears to be the "best" solution on macOS and the recommended solution for VS Code , Jupyter and matplotlib
• virtualenv isn't going away any time soon, and pipenv is built around it. If pipenv has any merrit (which it seems on skimming that it does), then I may want to write tooling around both
• I don't like the virtualenvwrapper stuff, that's why I wrote my fns in the first place
• Where does Anaconda sit within all this? I think it's can remain on the side as it currently is handled by my existing fns.

from dotfiles.

More notes:

This answer to the SO question above recommends venv over everything.

A work colleague recommends pyenv (yet another "only one obvious way to do it"). pyenv manages multiple Pythons much like rbenv/Node.js (forked from rbenv) and it has a plugin for virtualenv, called pyenv-virtualenv, which automatically will use python -m venv when available, and virtualenv is unavailable.

It also supports Anaconda/Miniconda.

Perhaps I should abandon my wrapperns or switch them to this?

from dotfiles.

more to read:

• https://docs.python-guide.org/dev/virtualenvs/
• https://packaging.python.org/tutorials/installing-packages/#creating-virtual-environments
• https://docs.python.org/3/library/venv.html#venv-def

from dotfiles.