Until now, the Python environment was handled by pyenv, but I often hear it, so I tried using virtualenv. At the same time, install virtualenvwrapper.

Pre-environment

Like this

$ pyenv versions 
  system
* 3.5.2 (set by /Users/hikaru/.pyenv/version)

Installation

Install in the environment of python 3.5.2.

$ pyenv version
3.5.2 (set by /Users/hikaru/.pyenv/version)
$ pip install virtualenv virtualenvwrapper

setup

Write the following in .bashrc

export WORKON_HOME=$HOME/.virtualenvs
source $PYENV_ROOT/versions/3.5.2/bin/virtualenvwrapper.sh

Execute the following command.

$ mkdir ~/.virtualenvs
$ source ~/.bashrc

I was addicted to the location of the source virtualenvwrapper.sh. There is also a file called $ HOME / .pyenv / shims / virtualenvwrapper.sh, but this is different from the one above. Or rather, when I sourced this, the terminal was exited.

move

Building the environment

$ mkvirtualenv django
Using base prefix '/Users/hikaru/.pyenv/versions/3.5.2'
New python executable in /Users/hikaru/.virtualenvs/django/bin/python3.5
Also creating executable in /Users/hikaru/.virtualenvs/django/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/predeactivate
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/postdeactivate
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/preactivate
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/postactivate
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/get_env_details
(django) $ pip list -l --format=columns
Package    Version
---------- -------
appdirs    1.4.3  
packaging  16.8   
pip        9.0.1  
pyparsing  2.2.0  
setuptools 35.0.2 
six        1.10.0 
wheel      0.29.0

With this feeling, an environment called django was created. Only the minimum required packages are included.

Exit the environment

(django)$ deactivate
$

You can enter each environment by displaying the environment list with the workon command and selecting the environment as an option.

$ workon 
django
$ workon django
(django) $

Delete environment

$ rmvirtualenv django
Removing django...
$

Environment construction by specifying Python

When I ran mkvirtualenv under python3.5.2, I got python3.5.2 environment, but I can explicitly use other python.

$ mkvirtualenv --python=/usr/bin/python2.7 django
Running virtualenv with interpreter /usr/bin/python2.7
New python executable in /Users/hikaru/.virtualenvs/django/bin/python
Installing setuptools, pip, wheel...done.
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/predeactivate
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/postdeactivate
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/preactivate
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/postactivate
virtualenvwrapper.user_scripts creating /Users/hikaru/.virtualenvs/django/bin/get_env_details
(django) $ python --version
Python 2.7.10
(django) $

Python 2.7.10 is working properly.

Summary

If you don't need to manage packages for each version of python, you probably don't need virtualenv. On the other hand, if there are packages that adversely affect each other or if detailed version specification is required, It seems better to turn off the environment with virtualenv.

A story of trying out pyenv, virtualenv and virtualenvwrapper