$ pyenv virtualenv 3.8.0 tf12 creates a virtualenv located in ~/.pyenv/versions/3.8.0/envs/tf12 which contains packages we installed into it using pip install. If we create a new project directory like mkdir myfolder && cd myfolder && pyenv local tf12, that project directory will use the same kernels and packages that the tf12 environment contains because we used the pyenv local command.
But then we also have virtualenvs and directories created with mkproject mynewenv located somewhere like ~/.ve and ~/workspace. The workspace is where we place notebooks, code and scripts .pynb, .py, .r etc and the corresponding virtualenv uses the global python version that was active when executing mkproject mynewenv.
These virtualenvs created with mkproject mynewenv are separate from virtualenvs created with pyenv virtualenv.
I have come to the conclusion that we cannot use them together for further possibilities. They are used independently. Correct me if I'm wrong.
You should install pyenv-virtualenvwrapper plugin and set it up. After that you can set up the python version and then create a virtual env.
pyenv local 3.8.0
mkvirtualenv test-venv
You can create a shell function to condense those two lines into one line if you want.
If you don't want to use pyenv local command to avoid creating a .python-version file, you can use pyenv shell <python-version> command instead.
# .bash_profile or .zshrc after pyenv and virtualenvwrapper init.
mkvenv()
{
pyenv shell $1
mkvirtualenv $2 ${@:3}
}
Remember that using mkvirtualenv test-venv -p python<version> won't pick up python versions installed by pyenv.
Another method: If you just want to create a venv with mkvirtualenv, you can use a shell function to replace it's behavior.
# .bash_profile or .zshrc after virtualenvwrapper init.
pyvenv()
{
python$1 -m venv $WORKON_HOME/$2
workon $2
}
To create virtualenv, use pyvenv <python-version> <venv-name>. You can use all virtualenvwrapper commands with the newly created venv.