Refer to the pip development documentation - it applies equally to virtualenv, except that virtualenv issues should be filed on the virtualenv repo at GitHub.

Virtualenv’s release schedule is tied to pip’s – each time there’s a new pip release, there will be a new virtualenv release that bundles the new version of pip.

Files in the virtualenv_embedded/ subdirectory are embedded into itself as base64-encoded strings (in order to support single-file use of without installing it). If your patch changes any file in virtualenv_embedded/, run tox -e embed to update the embedded version of that file in; commit that and submit it as part of your patch / pull request. The tox run will report failure when changes are embedded, as a flag for CI.

The codebase should be linted before a pull request is merged by running tox -e fix_lint. The tox run will report failure when any linting revisions are required, as a flag for CI.

Running the tests

The easy way to run tests (handles test dependencies automatically, works with the sdist too):

 $ tox

 Note you need to first install tox separately by using::

$ python -m pip --user install -U tox

Run python -m tox -av for a list of all supported Python environments or just run the tests in all of the available ones by running just tox.

Status and License

virtualenv is a successor to workingenv, and an extension of virtual-python.

It was written by Ian Bicking, sponsored by the Open Planning Project and is now maintained by a group of developers. It is licensed under an MIT-style permissive license.