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 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?

Coverture

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. – Leverrier

Answer 1

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

Genovese

nice I hadnt ever looked into the pip stuff but if i need to some day this will come in handy – Tragacanth

pip is very popular in the Django community and very easy to use. – Genovese

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. – Coverture

Is it possible to move a virtual environment after it has been created? I un-wittingly put it inside of my project directory – Dopp

Not a great justification IMO. Isn't this what .gitignore is for? – Rotation

@JoshNoe isn't .gitignore the thing you normally forget and your repo explodes and credentials end up on github? ;) – Florencio

*"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). – Strickman

Answer 2

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.

Mehalick

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!). – Frigidarium

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? – Orwin

@Orwin 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. – Mehalick

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." – Fuld

@Fuld 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. – Mehalick

Answer 3

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/

Bloomsbury

Answer 4

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.

Effectually

Answer 5

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.

Mundt

I don't think a sharp memory is necessary. If my virtual environments remain in my project directories, I already know where to find them. – Bertsche

Answer 6

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

Picul