Where should virtualenvs be created?

Question

I\'m confused as to where I should put my virtualenvs.

With my first django project, I created the project with the command

django-admin.py startproj         


        

Answer 1

The generally accepted place to put them is the same place that the default installation of virtualenvwrapper puts them: ~/.virtualenvs

Related: virtualenvwrapper is an excellent tool that provides shorthands for the common virtualenv commands. http://www.doughellmann.com/projects/virtualenvwrapper/

Answer 2

If you use pyenv install Python, then pyenv-virtualenv will be a best practice. If set .python-version file, it can auto activate or deactivate virtual env when you change work folder. Pyenv-virtualenv also put all virtual env into $HOME/.pyenv/versions folder.

Answer 3

From my personal experience, I would recommend to organize all virtual environments in one single directory. Unless someone has extremely sharp memory and can remember files/folders scattered across file system. Not a big fan of using other tools just to mange virtual environments. In VSCode if I configure(python.venvPath) directory containing all virtual environments, it can automatically recognize all of them.

Answer 4

Many people use the virtualenvwrapper tool, which keeps all virtualenvs in the same place (the ~/.virtualenvs directory) and allows shortcuts for creating and keeping them there. For example, you might do:

mkvirtualenv djangoproject

and then later:

workon djangoproject

It's probably a bad idea to keep the virtualenv directory in the project itself, since you don't want to distribute it (it might be specific to your computer or operating system). Instead, keep a requirements.txt file using pip:

pip freeze > requirements.txt

and distribute that. This will allow others using your project to reinstall all the same requirements into their virtualenv with:

pip install -r requirements.txt

Answer 5

Changing the location of the virtualenv directory breaks it

This is one advantage of putting the directory outside of the repository tree, e.g. under ~/.virtualenvs with virutalenvwrapper.

Otherwise, if you keep it in the project tree, moving the project location will break the virtualenv.

See: Renaming a virtualenv folder without breaking it

There is --relocatable but it is known to not be perfect.

Another minor advantage: you don't have to .gitignore it.

The advantages of putting it gitignored in the project tree itself are:

• keeps related stuff close together.
• you will likely never reuse a given virtualenv across projects, so putting it somewhere else does not give much advantage