Introducing Virtualenvwrapper, which makes it easy to use the functions of virtualenv that creates a unique environment for Python, and basic usage on Mac OS X.
Virtualenv alone is easy enough to use, but with the introduction of wrappers
I think that it is worth putting in because there are merits such as. Also supports Python 3.x series.
Can be dropped from pip. Since it is a tool that manages each environment, the wrapper itself is installed globally.
$ sudo pip install virtualenvwrapper
It is not ready for use just by installing it. Add the following settings to the login shell (* 1).
### Virtualenvwrapper
if [ -f /usr/local/bin/virtualenvwrapper.sh ]; then
export WORKON_HOME=$HOME/.virtualenvs
source /usr/local/bin/virtualenvwrapper.sh
fi
This is as you see it
If you have /usr/local/bin/virtualenvwrapper.sh (= if virtualenvwrapper is installed), set WORKON_HOME to run virtualenvwrapper.sh.
Since the PATH of virtualenvwrapper.sh depends on the environment
$ which virtualenvwrapper.sh
Check with. WORKON_HOME specifies the folder where each environment created by virtualenv is stored. If you do not have one environment created yet, you can leave the above settings.
(* 1) .bashrc, .bash_profile, .profile, etc. In my case, I'm using zsh, so it's .zshrc.
If you already have an environment created, you can see the list with the workon command.
$ workon
sandbox2
sandbox3
It can be created with mkvirtualenv [environment name].
$ mkvirtualenv --python=/usr/local/bin/python3 testdayo
Running virtualenv with interpreter /usr/local/bin/python3
Using base prefix '/usr/local/Cellar/python3/3.3.2/Frameworks/ Python.framework/Versions/3.3'
New python executable in testdayo/bin/python3.3
Also creating executable in testdayo/bin/python
Installing Setuptools...done.
Installing Pip...done.
$(testdayo)
As with virtualenv alone, you can specify the python to use with the --python option. After execution, a unique environment called testdayo is created and automatically switched from global to that unique environment.
Make sure that the virtual environment is created in the directory specified by WORKON_HOME above.
You can switch to the created unique environment with workon [environment name]. If you want to exit the system (global) from the unique environment once entered, type the deactivate command.
Currently, I was in the testdayo environment created in ↑, so let's exit with deactivate.
$(testdayo) deactivate
$
Try switching to testdayo again.
$ workon testdayo
$(testdayo)
If you are in a unique environment, the environment name is specified in parentheses, so it is easy to understand.
To delete the created virtual environment, exit globally and type rmvirtualenv [environment name].
$ rmvirtualenv testdayo
Removing testdayo...
$
Another advantage of using virtualenvwrapper is that it can be described so that specific processing is performed at the timing of creating, switching, and deleting the environment as described above. There are various hook points such as preactivate, predeactivate, and postdeactivate that execute a specific process. For details, refer to the document ↓
Extending Virtualenvwrapper - virtualenvwrapper
The files corresponding to these hook points
[WORKON_HOME PATH of virtualenvwrapper] / [environment name] / bin /
Since it is under the control, it is good to write the shell script you want to execute there. For example, if you want to execute test.sh when switching to a certain environment, the corresponding hook point is postactivate, so
[WORKON_HOME PATH of virtualenvwrapper] / [environment name] / bin / postactivate
To
#!/usr/local/bin/zsh
# This hook is run after this virtualenv is activated.
source test.sh
You can write it as. The first line should match the execution environment of your shell (#! / Bin / bash, etc.).
Recommended Posts