Python venv and virtualenvwrapper combined

Question

In Python 3.5 the recommended way to create virtual environments is with the venv, instead of virtualenv. Still the python packaging tutorial mentions both tools.

However virtualenvwrapper is a recommended wrapper tool to use when using virtualenv.

My questions are then:

1. Is there a way to use virtualenvwrapper with venv?
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)

Edit: I can see that there is some confusion in the answers to my question. venv is Python's official equivalent of virtualenv, as explained in the links above. Multiple stack overflow questions suggests that venv should be used. As mentioned in the "duplicate" you suggested:

the introduction of venv is in part a response to that mess. If you want to help improve the situation, I suggest you use venv and encourage others to do the same

So it is encouraged to use venv. But as this questions implies, if one is to use venv how does one use a wrapper like virtualenvwrapper

Answer 1

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
}

Answer 2

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 Handling
export WORKON_HOME=$HOME/.venvs  # Default name changed from virtualenv to highlight I am using python3 -m venv (aka pyvenv)
export PROJECT_HOME=$HOME/dev
source /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.