Is virtualenv recommended for django production server?
Question:
I have always been using virtualenv for testing my app in localhost since I have isolated environment and can safely test new release of packages.
Now It comes the time when I have to deploy my app to a production server. I am wondering if I should also use virtualenv for production server or just normal installation should do. Since it’s production server I can always use the correct version that I tested in the dev server (under virtual-env)
Answers:
I would do it that way if you ever think you’ll run more than one project on the webserver. As soon as you have two projects you run the risk of a future upgrade of any python package breaking the other site.
I think its a good indication that its a fully supported production solution when uwsgi directly supports it with the vhost flag: http://projects.unbit.it/uwsgi/wiki/VirtualHosting
Yes, I think you should use virtualenv to deploy it into production. It makes things a lot easier and cleaner for you, especially if you plan on deploying multiple services, e.g. django based websites or other python projects. You don’t want each of them to be polluting the global python environment with their packages.
I think virtualenv will help you manage all your dependencies cleanly.
To update your production env all you need to do is to:
pip -r name_of_your_requirements_file.txt
I use virtualenvs in production, and you can use uWSGI to serve the applications, with Cherokee as a web server.
To use your virtualenv in production, you will need to add its path to your PYTHONPATH.
For example if your env has the path “/home/www/my_project/env/”, the path to add would be:
/home/www/env/lib/python2.7/site-packages/
You can set this up in many different ways, but if you’re generating your FCGI or uWSGI interface through manage.py, simply add the following at the very top of your manage.py (before the rest):
import os
my_virtualenv_path = "/home/www/my_project/env/lib/python2.7/site-packages/"
# Add it to your PYTHONPATH
os.path.append(my_virtualenv_path)
You can adapt this to your setup, just in case you could also do the following in the shell:
export PYTHONPATH:$PYTHONPATH:/home/www/my_project/env/lib/python2.7/site-packages/
You will also need to add the directory that contains your settings.py file to the PYTHONPATH, so Django will be able to discover it. Just proceed in a similar manner to do so.
Is virtualenv recommended for django production server?
Yes, it makes your project not depend on certain aspects of the system environment and also it allows you to make the deployment process more clear and configurable.
I use fabric, pip and virtualenv to deploy all my Django projects.
In most cases I would agree it is best to have a virtualenv even if it doesn’t seem like you need it when you first set up the server. That said if you are using some kind of cloud service and spinning up servers for a specific task for a short time then I don’t see the point of using a virtualenv.
Using Docker containers for both development and production deployment is pretty popular now, so if you’re considering following this trend, you won’t need virtualenv anymore.
I have always been using virtualenv for testing my app in localhost since I have isolated environment and can safely test new release of packages.
Now It comes the time when I have to deploy my app to a production server. I am wondering if I should also use virtualenv for production server or just normal installation should do. Since it’s production server I can always use the correct version that I tested in the dev server (under virtual-env)
I would do it that way if you ever think you’ll run more than one project on the webserver. As soon as you have two projects you run the risk of a future upgrade of any python package breaking the other site.
I think its a good indication that its a fully supported production solution when uwsgi directly supports it with the vhost flag: http://projects.unbit.it/uwsgi/wiki/VirtualHosting
Yes, I think you should use virtualenv to deploy it into production. It makes things a lot easier and cleaner for you, especially if you plan on deploying multiple services, e.g. django based websites or other python projects. You don’t want each of them to be polluting the global python environment with their packages.
I think virtualenv will help you manage all your dependencies cleanly.
To update your production env all you need to do is to:
pip -r name_of_your_requirements_file.txt
I use virtualenvs in production, and you can use uWSGI to serve the applications, with Cherokee as a web server.
To use your virtualenv in production, you will need to add its path to your PYTHONPATH.
For example if your env has the path “/home/www/my_project/env/”, the path to add would be:
/home/www/env/lib/python2.7/site-packages/
You can set this up in many different ways, but if you’re generating your FCGI or uWSGI interface through manage.py, simply add the following at the very top of your manage.py (before the rest):
import os
my_virtualenv_path = "/home/www/my_project/env/lib/python2.7/site-packages/"
# Add it to your PYTHONPATH
os.path.append(my_virtualenv_path)
You can adapt this to your setup, just in case you could also do the following in the shell:
export PYTHONPATH:$PYTHONPATH:/home/www/my_project/env/lib/python2.7/site-packages/
You will also need to add the directory that contains your settings.py file to the PYTHONPATH, so Django will be able to discover it. Just proceed in a similar manner to do so.
Is virtualenv recommended for django production server?
Yes, it makes your project not depend on certain aspects of the system environment and also it allows you to make the deployment process more clear and configurable.
I use fabric, pip and virtualenv to deploy all my Django projects.
In most cases I would agree it is best to have a virtualenv even if it doesn’t seem like you need it when you first set up the server. That said if you are using some kind of cloud service and spinning up servers for a specific task for a short time then I don’t see the point of using a virtualenv.
Using Docker containers for both development and production deployment is pretty popular now, so if you’re considering following this trend, you won’t need virtualenv anymore.