Virtualenv instructions in README.md

[svaksha]

I wanted to add a link to our Bangalore mailing list to the locations page, and came across this line in the Readme.md file "It is important that when you create your virtualenv, do not create it in the same folder as the code you downloaded."

That line was confusing as I already have a virtualenv where I create a separate directory/folder for each project (depending on 2.x or 3.x) and then clone the repo with git. So, the order gets reversed as: 3.Create a virtualenv called PyLadies, and then, 2.Clone to your machine.
However, the Readme instructions seem to suggest otherwise

[econchick]

wat?! We're not supposed to have the virtualenv in the same dir as the cloned code?!? I know that says that in the README but is that really best practice?

[merwok]

It is, see how virtualenvwrapper works. What virtualenv does is actually not complicated, but many people are confused by it, and imo this confusion leads to non-optimal patterns such as creating the venv alongside the source code. I’ll expand more later : )

[econchick]

So I had the realization just now that because of the way that I originally setup virtualenv and wrapper, it sets up the virtualenv elsewhere, in ~/.venv

But yeah, you're right that the executables should not be where your git repo is. We don't want to see the bin/ dir in there.

If you set up virtualenvwrapper the way that it shows you in the docs (where the actual env is in ~/.venv or some other directory), then it doesn't matter which order you do it (git clone then mkvirtualenv or vis-versa).

I was just confused because I always git cloned then mkvirtualenv not even realizing that the actual venv is elsewhere. Don't judge...it's Friday.

[svaksha]

@merwok , I should have been explicit. Here is how I do it:
1.] cd .virtualenvs/
2.] mkvirtualenv --python=/usr/bin/python3.3 pyladiesCom --no-site-packages (# assuming the repo supports 3.x.)
3.] source pyladiesCom/bin/activate
4.] workon pyladiesCom (# note the foldername is different and this is where the /bin, /lib and /include folders are located as I only clone the "pyladies" git repo in the next steps.)
5.] cd pyladiesCom/
6.] git clone git@github.com:pyladies/pyladies.git

Currently, this is how the 'pyladies' repo looks:
/.virtualenvs/pyladiesCom/pyladies$ ls
atl boston dc LICENSE mtl pdx requirements.txt sf tunisia vienna
berlin CONTRIBUTING.md helsinki london nyc README.md sandiego TODOs.md tw www

This method seems cleaner and keeps my virtualenv packages and dependencies away from my code repo. Feel free to let me know if any steps need to be changed, and if you think its ok, I'm happy to include these steps in the README file. Thanks.

[merwok]

The steps you describe confuse me a little. First, you don’t need to cd and source activate: mkvirtualenv will work in the defined $WORKON_HOME directory without you needing to cd there.

Second, workon merely sources activates and runs post-activate hooks, so if you run it after step 3 it does nothing.

Your repository does not have to (and IMO should not) be located in your virtualenv. Venvs are throw-away.

I’m busy now but will write more later with links to the venv and venvwrapper docs.

[svaksha]

On Mon, Aug 19, 2013 at 5:00 PM, Éric Araujo notifications@github.com wrote:

First, you don’t need to cd and source activate: mkvirtualenv will work in the defined $WORKON_HOME directory without you needing to cd there.

True. Fwiw, I use the 'mkvirtualenv' command only while creating a new
venv for cloning a repo. For activating an existing repo, its
'virtualenv'

Second, workon merely sources activates and runs post-activate hooks, so if you run it after step 3 it does nothing.
Ok.

Your repository does not have to (and IMO should not) be located in your virtualenv. Venvs are throw-away.

While I agree that venv's are throw-away, care to explain why the repo
should not be located inside the env - fwiw, the repo is inside
another directory (note the path: /.virtualenvs/pyladiesCom/pyladies
<-- this is where the pyladies repo sits, whilst /pyladiesCom contains
the /bin and /lib

svaksha ॥ स्वक्ष

[econchick]

@svaksha it's bad to have executables in your git repo.

Here's my layout:

/Users/lynnroot/.virtualenvs/pyladies.com
/Users/lynnroot/Dev/pyladies.com

Whenever I am about to start a project, I am within my ~/Dev directory, and I clone a project, e.g. git clone https://github.com/pyladies/a-new-project which starts a new directory inside ~/Dev, or create a new directory my-new-project and just do git init.

Then I make or turn on the virtual env. The mkvirtualenv and workon <env_name> is tied to the $WORKON directory, and the executables within the env directory. When you downloaded and installed the virtualenvwrapper package, it tells you to export the $WORKON dir and source it. So for instance, when I'm working on PyLadies, I do workon pyladies.com. Now I have access to the libraries and python version I want (rather than the default system python and the libraries that are installed globally).

There's actually no physical relation between the $WORKON/env dir and the ~/Dev/pyladies.com dir....yet. I just happened to run the workon pyladies.com command in ~/Dev/pyladies.com. Theoretically, if I wanted to use the same libraries and same python version on another project, for whatever reason, I can leave the virtualenv "on", and move to another directory, like ~/Dev/SQLadies.

If I want to map a virtualenv to a project directory, I can, within the desired project dir, do setvirtualenvproject. Or from the start, pair the virtualenv and the project directory with mkproject. Doug's docs here [http://virtualenvwrapper.readthedocs.org/en/latest/command_ref.html#mkproject] show there's a clear difference between envs and project dirs.

[econchick]

If this still remains an issue, please reopen to discuss.