[crdoconnor]

I hate the whole idea of activating virtualenvs. It's a tool that makes it really easy to end up running a command in the wrong environment and see weird behavior instead of a clear error message.

I've seen variations on this scenario happen at least 3 times, for instance:

1) Somebody creates script that activates and runs django and commits it.

2) Junior runs script but the virtualenv doesn't get created for some reason.

3) The "warning virtualenv doesn't exist" message appears briefly and gets missed.

4) The junior gets "import error: cannot import django" or something.

5) They then start installing django in their system environment and... it sort of works. Except then they get another import error. And a whole bunch of python packages installed in their system environment. Yech.

Moreover, I'm really not sure what was so wrong with just running ./venv/bin/python in the first place and never having to worry about what environment you're in.

[falsedan]

> 1) Somebody creates script that activates and runs django and commits it.

You can call the python bin inside the virtualenv and it will run as if the virtualenv was active:

  venv/bin/python -m foo.bar

Obviously it doesn't work if devs used different names for their virtualenvs. Work has a convention to always use the same name so this works pretty well.

[spapas82]

That's 7 characters more you'll need to write all the time! Also you'll need to remember to prepend them to all scrips, ie pip, fab etc. Well that seems to me to be more error prone for juniors than telling them to always use a virtual env (ie have (envnane) in their prompt)!!

[crdoconnor]

It's less error prone. Never had ^^ that scenario since and I've not run into additional problems either.

Having an extra 7 characters in a ./run.sh script doesn't really bother me. I'm not a perl developer.