When using :python or :!python, it will only have access to the environment outside of any virtualenvs. If you're working with packages that are only installed in a virtualenv, they will not be available to Vim.

Until now! The virtualenv.vim plugin will modify python's sys.path and the $PATH environment variable so that anything done with :python or :!python will behave like you would expect for the chosen virtualenv.

If compiled with python support, Vim will have a :python command, but this will be tied to whatever version is the default on your system. If this is the version of python that you use, or you're using a Linux distribution with a sensible package manager (like Debian or Ubuntu), you likely will not have to do anything more than install the plugin. If not, then you will likely have to recompile vim with your version of python.

The plugin is even smart enough to handle situations where Vim inherits an active virtualenv from the shell. The plugin can switch between and deactivate those virtualenvs all the same.

Deactivate the current virtualenv

:VirtualEnvDeactivate

List all virtualenvs

:VirtualEnvList

Activate the 'spam' virtualenv

:VirtualEnvActivate spam

If you're sure which one to activate, you could always use tab completion

:VirtualEnvActivate <tab>

If the shell that started vim had $VIRTUAL_ENV set, omitting the name will imply usage of this value.

If you're a virtualenvwrapper user and have $PROJECT_HOME set, omitting the name will try to guess which virtualenv to activate based on the current filename.

You can even show the current virtualenv in the statusline with the included function

Or, for those with a properly configured Powerline (the virtualenv segment is not enabled by default), your virtualenv indicator will toggle on or off accordingly.

The plugin also supports relative paths for the location of your virtualenvs. Locations such as ./venv or ../venv are supported in case you like to package your virtualenvs inside or relative to your project code. Care is taken to ensure that this location exists before defaulting back to the value of $WORKON_HOME if you are a virtualenvwrapper user or ~/.virtualenvs as a last resort. This has the pleasant side-effect of allowing access to two sets of virtualenvs depending on what your current directory is; a project-specific set of virtualenvs located in the relative location, or a general set located in either of the other two fallback locations.

For more detailed help

:help virtualenv