Is there a reason you don't "activate" your virtualenv?
That (with the addition of using mkvirtualenv and friends) is the workflow I use to both dev and prod and am really happy with!
That (with the addition of using mkvirtualenv and friends) is the workflow I use to both dev and prod and am really happy with!
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.
Having an extra 7 characters in a ./run.sh script doesn't really bother me. I'm not a perl developer.
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
Tools like nvm, rvm, ros ... If I can use a solution for managing a development context that doesn't involve mucking around with the shell environment I much prefer it. Configuration via the sourcing of shell scripts is a very fragile interface, doesn't work when with good (ie non-bash) shell, and almost always eventually leads to bugs when some workflow triggers processes in a manner that fails to inherit the shell environment...