We Keep Coding

What directory do I install a virtualenvironment? [duplicate]

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?

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

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.

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/

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.

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.

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

How do I set up a configured environment from a cloned repo?

I cloned a repo and I'm trying to run my tests and i'm getting an interpreter error:
Interpreter path does not exist: C:\Users\username\Source\Repos\citcodownloader\env\Scripts\python.exe
The project downloaded a .sln, solutions view that I opened it with and I thought it set up my enviornment but it doesn't seem to be doing so. Not sure what to do from here.

The best thing you can do is create a (or use an existing) Virtual Environment. It looks like your program is looking for one in the folder "env". Try this:
Open a terminal (Windows key + R, then type cmd and press enter)
Navigate to your repo folder using chdir C:\path\to\your\repo
Run the command env\Scripts\activate.bat (if there is no folder called "env" in your repo, use my instructions below)
Try running your program again.
I hope this helps, post a comment if it doesn't and I'll add as much detail or explanation as you need. Good luck!
For Googlers or people who that doesn't help, look for these files in your repo:
requirements.txt (a list of plugins you need to set up a virtual environment)
venv/ (folder containing a virtual environment)
Solution
If a folder named 'venv' or 'virtualenv' does NOT exist,
run this command to create it: python -m venv venv (or for Python 3: python3 -m venv venv). If it does exist, move forward.
You have a virtual environment! Now enter into it using: source venv/bin/active (on Unix or OSX, see the link above for the Windows command).
If requirements.txt is there, run this command next: pip install -r requirements.txt. If not, move forward.
Run the program again (via whatever method the repo says you should use). If you get 'error: module is not installed' use the command pip install moduleNameHere and run the program again.
Keep doing step 4 for each missing module, once the program is working use pip freeze > requirements.txt to create a requirements file and save yourself the headache next time. :)

Unable to git add env/bin directory after creating virtualenv

I am really new to Python and the virtualenv needed to set up a project. I dont know whether the directories generated by virtualenv should be gitignored or staged and committed.
I narrowed it down to the myproject/env/bin directory that doesn't seem to want to be staged. After running git add env/bin once I get.
[1] 16599 killed git add env/bin
And then after running the same git add env/bin again I get.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'....
There are no other git process running. Thanks for your help!

After looking through a few other Python/Django repositories on Github, I see that most have add the env/bin, env/include and env/lib directories (generated by virtualenv) to their .gitignore file. I'll take this at face value and move on til I have a better understanding of virtualenv. Thanks!

Should I commit /bin directory when working with virtualenv?

I am starting my first actual python project. I follow "Learn Python the Hard Way" to make an initial Python skeleton and I am using virtualenv too.
Now I want to use git to do the version control. According to some previous questions in SO, I am not suggested to commit any virtualenv files. Instead, I could use pip freeze > requirements.txt, and use .gitignore to ignore the virtualenv directories.
However, both virtualenv and Python project skeleton require a /bin directory, should I commit it as well? (Actually I don't really know what the role /bin is playing in Python project)
Any suggestions are appreciated, if there is something wrong with my process to set up a Python project, please correct me.

yourproject/bin is distinct from yourproject/env/bin, where yourproject/env is the virtual environment's directory (and neither of them is /bin in the root directory). You should ignore everything in env, and indeed, your project should work for someone who isn't using a virtual environment, or is managing it differently. Otherwise, you lose the benefits.
Let's imagine for a second that you finish your project, and I want to use it for a new task. I start a new project with a virtualenv of its own, and install some other components I want to use, and then yours. Oops, now I have an older version of Python than I started out with, and that bug in deactivate from two years ago somehow got resurrected. Imagine debugging that, let alone the annoyance of finding that your project replaced some files of mine.
(As these things go, the bin directory is a pretty static part of the virtual environment; zapping other parts of my private env would be much more destructive. If you committed lib you would have prevented me from installing any other components before yours.)

Directory change not occuring with setvirtualenvproject

I'm embracing VirtualEnvWrapper - and like what I see a lot. However as I try to get going I'm not seeing the behaviour I expect when trying to set up project directory association with virtual envs.
I've installed virtualenv and -wrapper. I can create envs and "workon" lists them fine. I can deactivate and rm them happily. So all appears functional. I read the docs regarding project mgmt. (Also a good video tutorial, and the desired proj association behaviour explained at 10:39 )
When I try to associate a work directory with an env, it accepts my cmds fine, but when I "workon" the project, it does not put me into my designated working directory.
e.g. I have a working area ~/Ross_code (and I've set this in my .bashrc as $PROJECT_HOME). In there is an existing project folder ~/Ross_code/superproj
So now I create an env with
mkvirtualenv superp
Then I go to my existing project dir and associate it with the env:
cd ~/Ross_code/superproj
setvirtualenvproject
Setting project for superp to /Users/ross/Ross_code/superproj
Then I exited the virtual env with "deactivate" and reactivated with
workon superp
But the present working dir remains my ~/ folder.
I checked the .project file which seems to have been set properly by the call to setvirtualenvproject:
cdvirtualenv
more .project
/Users/ross/Ross_Code/superproj
but calling "workon" never sticks me into the expected spot. I thought maybe the env and the project directory needed to be of the same name, but that didn't make any difference either.
Any idea why that very attractive project association capability doesn't work for me?
-Ross.
LATER - More info:
I tried to also use the mkproject command, which should create a directory for my code in the $PROJECT_HOME area, and create the virtualenv at the same time and associate them with each other.
Calling
mkproject junkproj
does in fact create the project directory nicely, and sticks me into the virtualenv, and cd's into the junkproj directory. But when I deactivate, and then "workon junkproj" again, I'm still left in my ~/ directory, rather than going into the project directory in $PROJECT_HOME
:(

The problem here is that the newer versions (this hit me upgrading from ubuntu 14.04 to 16.04) of virtualenvwrapper use a slightly different protocol for the setvirtualenvproject parameters:
setvirtualenvproject [virtualenv_path project_path]
In order to make the association you want in any virtual env, be in the project folder and the virtualenv and use:
setvirtualenvproject $VIRTUAL_ENV .
The dot is for the present directory - or you can use the path of the directory you want workon to take you to. Once you do this workon will switch you to the folder you want and cdproject will work as expected.
If you used the old protocol, you'll have a .project file in your project folder - you can move this to the $VIRTUAL_ENV folder rather than invoking the command with the new protocol to make the association. The file just contains the project directory you want to associate with virtualenvwrapper shortcut commands like workon and cdproject.

workon doesn't auto change directory to project or environment directory.
You can do this with the postactivate script - there's a really quick how-to in the second half of the virtualenvwrapper tips and tricks section.