141

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 startproject djangoproject

I then cd'd into the djangoproject directory and ran the command

virtualenv env

which created the virtual environment directory at the same level as the inner djangoproject directory.

Is this the wrong place in which to create the virtualenv for this particular project?

I'm getting the impression that most people keep all their virtualenvs together in an entirely different directory, e.g. ~/virtualenvs, and then use virtualenvwrapper to switch back and forth between them.

Is there a correct way to do this?

finefoot
  • 9,914
  • 7
  • 59
  • 102
Jim
  • 13,430
  • 26
  • 104
  • 155
  • On windows, I personally create an extra directory under `%USERPROFILE%\AppData\Local\mypythonenvs\``. For example I create `%USERPROFILE%\AppData\Local\mypythonenvs\python3-qiskit` for a Qiskit env. This way I don't have to worry about forgetting path after 2 months. – Rajesh Swarnkar Mar 29 '22 at 12:29

6 Answers6

158

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
Michael Hays
  • 2,947
  • 3
  • 20
  • 30
David Robinson
  • 77,383
  • 16
  • 167
  • 187
  • nice I hadnt ever looked into the pip stuff but if i need to some day this will come in handy – Joran Beasley Aug 29 '12 at 19:11
  • pip is very popular in the Django community and very easy to use. – David Robinson Aug 29 '12 at 19:12
  • Thanks David, that's kind of what I thought. I knew about the requirements thing and am doing that. I just wasn't sure about where the venv should go. Your comment about it being OS-specific is a good justification for doing what you suggest. – Jim Aug 29 '12 at 19:14
  • Is it possible to move a virtual environment after it has been created? I un-wittingly put it inside of my project directory – James Wierzba Dec 02 '15 at 19:56
  • 12
    Not a great justification IMO. Isn't this what .gitignore is for? – Josh Noe Jul 01 '18 at 20:40
  • @JoshNoe isn't .gitignore the thing you normally forget and your repo explodes and credentials end up on github? ;) – andreas Jun 24 '19 at 15:59
  • 2
    *"It's probably a bad idea to keep the virtualenv directory in the project itself, since you don't want to distribute it"... but many existing package managers for other languages do exactly that (e.g. Rust/cargo, Haskell/stack/cabal, JS/npm). – Mateen Ulhaq Sep 14 '21 at 21:35
38

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

This is an annoying design flaw in my opinion. They should implement virutalenv in a way that does not matter where the directory is, as storing in-tree is just simpler and more isolated. Node.js' NPM package manager does it without any problem. And while we are at it: pip should just use local directories by default just like NPM. Having this separate virtualenv layer is wonky. Node.js just have NPM that does it all without extra typing. I can't believe I'm prasing the JavaScript ecosystem on a Python post, but it's true.

Ciro Santilli OurBigBook.com
  • 347,512
  • 102
  • 1,199
  • 985
  • 4
    This is the only reasonable argument I've seen for creating virtualenv folders outside of project trees! Other guideance just seems to repeat 'centralization' dogma as if it were inherently a best practice instead of an unfortunate compromise due to virtualenvs being fundamentally broken (albeit quite useful!). – rob3c Sep 20 '18 at 19:16
  • Sorry something is not clear to me, so are you recommending creating it in the project tree and then"gitignoring" it or creating it in the ~/.virtualenvs ? What does "If it weren't for that" refer to? – aderchox Jul 13 '20 at 03:54
  • 2
    @aderchox there's a tradeoff: put it into project tree and it tree moves you have to reinstall, or put it on ~ but manage on extra subdir outside of project. – Ciro Santilli OurBigBook.com Jul 13 '20 at 07:27
  • 1
    Yet another in the long line of annoying design flaws and bad decisions in Python. Python 2/3 is another. I'm trying to use multiple Python applications, not develop them, and there is no better recommendation I can find than "create a brand new directory per application and create a venv in there." – Cliff Dec 19 '22 at 04:03
  • @Cliff yes. Python is a bit old. By the time people understood that Node and Ruby had the correct package management, Python political power was already too decentralized to make changes fast. Things are improving slowly I think. – Ciro Santilli OurBigBook.com Dec 19 '22 at 08:59
7

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/

Emmett Butler
  • 5,969
  • 2
  • 29
  • 47
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.

ugoren
  • 16,023
  • 3
  • 35
  • 65
Aston
  • 31
  • 2
2

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.

Tejas Sarade
  • 1,144
  • 12
  • 17
0

For Anaconda installations of Python, the "conda create" command puts it in a directory within the anaconda3 folder by default. Specifically (for Windows):

C:\Users\username\anaconda3\envs

This allows other conda commands to work without specifying the path. One advantage, not noted above, is that putting environments in the project folder allows you to use the same name for all of them (but that is not much of an advantage for me). For more info, see:
https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html