A very simple wrapper around python3's venv. This little script allows creating and using venvs well tucked away from your project code.
Put the venvworkon.sh script somewhere and source it in your
~/.profile or ~/.bashrc file.
The script only supports one usage mode:
$ workon [environment] [python version]
If environment is not provided, then the list of existing venvs will be printed instead.
The python you want to use must exist in the $PATH and start with
python. Pass the version suffix of the executable as the second
argument to the script. It'll be translated like so when creating
the venv:
workon foo 3.6 => python3.6 -m venv $WORKON_HOME/foo
When workon is called, venvs are created or loaded from the
$HOME/.venv folder by default.
To change this behavior, set the WORKON_HOME environment
variable before sourcing venvworkon.sh.
If the file $HOME/.venvs/<venv>/postactivate.sh exists, it is
automatically sourced after the venv is activated. This is useful
to export environment variable such as DJANGO_SETTINGS_MODULE.
If PROJECT_HOME is set (e.g. $HOME/Projects) and there is
a project folder which match the environment name, venvworkon
change the current working directory to the project directory.
If the script is able to find the path to your project, and
a .env file exists at the root of your project, then it
will be sourced automatically when activating the environment.
For the venvworkon to find the path of the project, it
either needs to be created through the shorthand . name, or
you need to have PROJECT_HOME set and your environment
name must match your project directory's name.
virtualenvwrapper is certainly much more feature-packed and
useful than this. But this wrapper is handy for development and
uses the light-weight pyvenv rather than virtualenv. Up to you.