2 ms·
Something for your fabfile (for pushing to production and migrating): def with_virtualenv(command): "Executes a command in this project's virtual envir
by Nagyman 16y ago
Something for your fabfile (for pushing to production and migrating):
def with_virtualenv(command):
"Executes a command in this project's virtual environment."
run('source /usr/local/bin/virtualenvwrapper.sh && workon %s && %s' % (env.virtualenvname, command), pty=True)
e.g. usage:
with_virtualenv('python manage.py migrate')
For your local development, throw the virtualenv wrapper initialization into your bashrc (Only need to do this once.)
echo "source /usr/bin/local/virtualenvwrapper.sh" >> ~/.bashrc
When you're developing, always start by activating your virtual environment.
- StavrosK 16y agoWhy would I need to do that? I can just change the shebang line in manage.py and never ever need to activate the virtualenv...
- Nagyman 16y agoOne of the big benefits of using virtualenv is that you can change the environment your code is running within. For example, if I want to test a new version of a package (or a new version of python altogether), I can create another virtual environment and "workon [newenvname]", ./manage.py runserver..., and test away. It also follows the principal of least surprise. As a developer, if I run a python file, I generally expect it to use the python version in my environment, not some hard coded path. This is exactly why manage.py references python in the environment (/usr/bin/_env_) and not a direct path to the python executable. It's easy to switch virtual environments and unexpected that I'd have to change code. I could be wrong.