Python venv and virtualenvwrapper combined

Here is a custom but still clean and clear solution. Append This script to in .bashrc / .bash_profile / .zshrc, it will give you basic management of venv.

In addition, you can extend the script by adding the following line so that it will also display the existing venv lists.

lsvenv(){    ls $VENV_HOME}

1. Is there a way to use virtualenvwrapper with venv?

Yes. Simply point WORKON_HOME at your venvs directory. Here's what I do in my ~/.zshrc, and I use a mix of virtualenv (rare now, just for a few legacy py2 needs) and venv (most common). I renamed the default to .venvs to make it clear these are mostly Python 3 venvs and not virtualenvs.

# Python Environment Handlingexport WORKON_HOME=$HOME/.venvs  # Default name changed from virtualenv to highlight I am using python3 -m venv (aka pyvenv)export PROJECT_HOME=$HOME/devsource /usr/local/bin/virtualenvwrapper.sh  # symlinked to /Library/Frameworks/Python.framework/Versions/3.7/bin/virtualenvwrapper.sh

2. Or could one even consider virtualenvwrapper not needed due to venv? (I cannot see how this could be true since it is a wrapper solving another problem)

venv == virtualenv (in short). venv does not supersede virtualenvwrapper for the same reason virtualenv does supersede it. Your hunch on this is correct.

3. How is this better than just making an alias that sources the activate?

Well, it's up to you to determine what you need, but I find virtualenvwrapper with zsh plugins virtualenv and virtualenvwrapper to be pretty great and better than raw aliases.

workon to list all venvs is very nice, then workon speech_analyzer to jump right in on it.

4. Other solutions?

You can also set up hooks to activate venvs on directory change, but if that's what you are after and only that, then that's essentially pipenv. Pipenv is great if that's all you want to do. Pipenv also has an interesting and promising lockfile feature, but it is too slow for development and too immature with issues in production to comment on at this time.

But I've never liked the 1:1 environment per project workflow for the same reasons given here: https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/. Particularly these needs line up with mine of the multi project single environment: https://chriswarrick.com/blog/2018/07/17/pipenv-promises-a-lot-delivers-very-little/#nikola

I have six environments on my machine and about 20 projects. Pipenv doesn't extend to that situation. Pipenv insists on 20 environments for 20 projects. It just doesn't work and creates more problems than it solves. If you do have a 1:1 workflow though currently, then pipenv may be the tool you'd like. One word of caution, you can ~only~ do that workflow in pipenv, unfortunately.

[EDIT, 8 Jul 19: Readers will probably find that this answer gives a fullerdescription of the different tools for handling virtual environmentsin Python. They all have their issues, as does conda, which has asomewhat more sophisticated concept of "environment".]

1. As its name suggests, virtualenvwrapper was specifically designed towrap virtualenv, on which it depends. I don't believe that anyonehas similarly wrapped venv yet.

2. venv is intended to do the basic work of creating virtualenvironments, but environment management has to be done withscripts. Although shell scripting is often people's firstresort, the venv module has an extensive API to help you inthose tasks.

Nowadays there are many options for creating Python virtual environments. Besides those you mention, anaconda allows the creation and management of environments and even works pretty well with pip most of the time.

The tools in the virtual environment space have been designed to work together with standard Python distribution tools as far as possible, but the arrival of venv in Python 3.5 did not invalidate either virtualenv or virtualenvwrapper, which should both still work fine.

The venv module is principally a simple toolkit to allow the creation of virtualenvs inside programs, and is by no means intended to replace the convenience of virtualenvwrapper. It simply meets a rather different set of needs.