CODEWITHSUNDEEP
djangoapachemod-wsgi
brsbilgic
brsbilgic

Reputation: 11833

Running two django app on apache with very similar files (project and project_development)

I have a django app runs on Apache with mod_wsgi and my wsgi file looks like :

import os
import sys

sys.path.append('/home/UNAME/DP/')
sys.path.append('/home/UNAME/DP/pr1/')

os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

I have also created another app as pr1_developer and its wsgi is :

import os
import sys

sys.path.append('/home/UNAME/DP/')
sys.path.append('/home/UNAME/DP/pr1_developer/')

os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()

However, in my 'views', 'urls', 'models','forms' and other python files import necessary classes as 

from pr1.main.models import Country,City, Months
from pr1.employer.models import EmployerStatus
...

However, when I try to run pr1_developer application I need to change the headers like from pr1.main.. to pr1_developer.main.. in every file.Otherwise pr1_developer runs the modules from pr1.

As you except, I don't want to create two different files for each project but how can I overcome such difficulty ?

One approach may writing from main... instead of from pr1.main... however, I am not sure if it is a good way to do this.

I am appreciated for any suggestion.

Upvotes: 0

Views: 84

Answers (2)

chernevik
chernevik

Reputation: 4000

tldr; Might be better to use virtualenv.

I am but an egg but I think the gurus will discourage from messing around with sys.path. My excursions with it have made my code less portable among hosts and projects, introduced weird breakage points (for instance, sometimes equality tests fail b/c when one object has class 'pr1.main.models' and another 'pr1.test.main.models') and created dependencies that I've later had trouble remembering. These efforts were generally attacks on some dimly-understood problem of project or workflow management. The sys.path solutions weren't worth the technical debt they introduced.

Using sys.path usually means some structural problem of a sort that, as a newbie, I haven't dealt with often and then didn't understand very well. This stuff always comes up when I'm in a hurry to get something else done, but I'm trying to remember that getting this sort of thing right makes everything else easier down the road.

A tool like virtualenv might serve you better. You'd have a pr1 environment, with the initial code, and a pr1_dev environment with different code (but the same module names). You could have one terminal window running the one and another running the other. When something in _dev is ready for primetime it can be moved in without changing its imports or namespace references. Of course, you'll have to spend time learning another tool rather than pushing forward whatever it is you're working on.

See http://pypi.python.org/pypi/virtualenv for virtualenv. Doug Hellman has also written mkvirtualenv (http://doughellmann.com/2008/05/01/virtualenvwrapper.html), a bash level script for managing the environments.

Upvotes: 1

brorfred
brorfred

Reputation: 492

Isn't it easier to instead use two instances of the same projects?

devel.wsgi:

sys.path.append('/home/UNAME/devel/DP/')
sys.path.append('/home/UNAME/devel/DP/pr1/')

and

production:

sys.path.append('/home/UNAME/production/DP/')
sys.path.append('/home/UNAME/production/DP/pr1/')

Point Apache to the two respective folders and wsgi files.

This way, you can have the entire codebase in version control, commit for devel and checkout into production without having to change anything.

Upvotes: 1

Related Questions