How to use properly Pyenv and venv?

Question

Articles read:

Python Virtual Environments: A Primer,

Pyenv – Install Multiple Python Versions for Specific Project,

How to manage multiple Python versions and virtual environments

Let's suppose we have these directories:

 ~/Projects/PyA : it'll use Python 3.4.3 with Django 2.0
 ~/Projects/PyB : it'll use Python 3.5.1 with Django 2.1
 ~/Projects/PyC : it'll use Python 3.5.6 with Django 2.2
 ~/Projects/PyD : it'll use Python 3.2 with python-igraph

The first to do, we install Python versions needed:

$ pyenv install 3.4.3
$ pyenv install 3.5.1
$ pyenv install 3.5.6
$ pyenv install 3.2

My doubts start here:

Should I do this?

$ cd ~/Projects/PyA && pyenv local 3.4.3 && python3.4 -m venv proA
$ cd ~/Projects/PyB && pyenv local 3.5.1 && python3.5 -m venv proB
$ cd ~/Projects/PyC && pyenv local 3.5.6 && python3.5 -m venv proC
$ cd ~/Projects/PyD && pyenv local 3.2 && python3.2 -m venv proD

When is an unique directory for virtual environments used? Which option is recommended? Why?

How should I install per-project packages listed above?

Should I use virtualenvwrapper?

How do I switch between projects (changing Python/virtual-environment in the process) easily or painlessly?

In Ruby, there is a file named Gemfile where I can set which gems (with their respective versions) are installed for the current project, which is a very good idea, is there something similar for Python?

Thanks in advance.

PS: I use ArchLinux as guest for vagrant box.

EDIT 10/10/18: Very thanks folks for you answers. But I request with the greatest respect to all of you if you could answer specifically every question asked for me, please. I learn better with practical examples more than theory.

Answer 1

Edit to adress all your questions:

When is an unique directory for virtual environments used? Which option is recommended? Why?

Every virtual environment "lives" in its own folder. All packages you install will go there, especially if every environment will have a different python version.

How should I install per-project packages listed above?

When you switch to the project environment after you created it, see my original answer below, all packages installed will exclusively be installed into that virtual environment you are currently working in.

You can always check which python is currently in use by typing

which python

in the terminal you currently have the the project environment activated. In addition you can also check

which pip

to make sure if you are installing using pip install somepackage that you target the correct python. If you want to pin the packages, you can do

pip freeze > requirements.txt

any time and the currently installed packages plus their version will be written to the textfile requirements.txt. You can now always create a new environment using

pip install -r requirements.txt

Should I use virtualenvwrapper?

I would always work in a per project virtual environment so other projects that may use some pinned version of a special package are not influenced.

How do I switch between projects (changing Python/virtual-environment in the process) easily or painlessly?

You could define an alias in your ~/.bashrc or ~/.bash_aliases. In a terminal open (in my example) the ~/.bashrc with a text editor e.g. vim/nano or one of your liking:

nano ~/.bashrc

and somewhere near the end you can add a line with an alias to switch to the project directory and activate the environment at the same time:

alias activate_proj1="cd ~/project_1 && pyenv activate venv_project_1"

so you only type activate_proj1 in the terminal (tab completion also works) and both commands are executed. Don't forget to source the bash-file again after you change something with source ~/.bashrc or just open a new terminal.

---

original answer:

pyenv will handle everything you need:

My workflow (for one project to make it more readable) would be the following:

pyenv install 3.5.1
cd python_projects
mkdir myproject
cd myproject
pyenv virtualenv 3.5.1 venv_myproject

After that you can simply activate the virtualenv created by pyenv using

pyenv activate venv_myproject

which will open your distinct environment. Here you can do all the things you want, e.g. install your packages using pip etc. After you completed setting up the environment, you can freeze the environment and create a requirements file:

pip freeze > requirements.txt

to be able to reconstruct the environment if needed. This way all the overhead that may be needed (setting a PATH etc.) will be handled by pyenv.

If you want to work on different projects, just activate the environment you need and off you go!

Note that you can make pyenv activate the virtualenv when you cd the folder in your terminal by putting it's name into your .python-version file as well.

Answer 2

There's a lot going on in this question.

virtualenv workflows are usually pretty simple. You create a directory for your project, cd into it, and run virtualenv venv for a simple virtualenv, but you can also specify which python executable you'd like in your virtual environment with a -p python3.5 for a python3.5 virtual environment, for instance. There's no magic going on here. You need python3.5 installed to create the python3.5 virtual environment. To activate this virtual environment, you simply source venv/bin/activate. Once activated, your shell should reflect which virtual environment you're operating in. You can even run which python to see that it's actually directed at the venv directory structure. Simple.

An analog to the Gemfile in python would be similar to what most projects use as a requirements.txt. These can be generated trivially by running pip freeze > requirements.txt or installed by running pip install -r requirements.txt. Generally, this is done within the context of a virtual environment to avoid disrupting or clobbering your operating system's global python packages.

Kenneth Reitz released a tool that incorporates virtualenv called pipenv and it looks very nice, but I've had some trouble breaking my habits of using virtualenv, and the truth is, virtualenv hasn't presented me with enough problems to deeply explore this new project, but your mileage may vary. Mr. Reitz's contributions to the python community are overwhelmingly positive, so it's definitely worth a look.