4 ms·

Do you need to modify your manage.py? source /usr/bin/local/virtualenvwrapper.sh workon yoursitevirtualenv ./manage.py migrate Virtualenv changes the cu

by Nagyman 16y ago

Do you need to modify your manage.py? source /usr/bin/local/virtualenvwrapper.sh workon yoursitevirtualenv ./manage.py migrate Virtualenv changes the current environment variables to use the correct python version. So the shebang in manage.py (/usr/bin/env python) will use the right version and installed packages. The upside is you can change your python version & packages without changing hard coded paths to the virtual environment you want to use.

StavrosK 16y ago
You don't, if you need to change envs for a single project. Otherwise, there's no reason why you need to type two(/three) commands when one will do...
- 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 ago
    Why 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 ago
      One 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.

by Nagyman 16y ago

StavrosK 16y ago

You don't, if you need to change envs for a single project. Otherwise, there's no reason why you need to type two(/three) commands when one will do...

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 ago
  Why 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 ago
    One 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.