Запуск двух приложений django на apache с очень похожими файлами (project и project_development) - PullRequest
Новая
       0

Запуск двух приложений django на apache с очень похожими файлами (project и project_development)

0 голосов
/ 21 ноября 2011

У меня есть приложение django, работающее на Apache с mod_wsgi, и мой файл wsgi выглядит так: 

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()

Я также создал другое приложение как pr1_developer, и его wsgi: 

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()

Однако в моих файлах 'views', 'urls', 'models', 'forms' и других файлах python импортируйте необходимые классы как 

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

Однако, когда я пытаюсь запустить приложение pr1_developer, мне нужно изменить заголовки, например from pr1.main.. на pr1_developer.main.. в каждом файле. В противном случае pr1_developer запускает модули из pr1.

Как и вы, я не хочу создавать два разных файла для каждого проекта, но как мне преодолеть такую ​​трудность?

Один из подходов может написать from main... вместо from pr1.main..., однако я не уверен, что это хороший способ сделать это.

Я ценю любое предложение.

Ответы [ 2 ]

1 голос
/ 21 ноября 2011

tldr; Может быть лучше использовать virtualenv.

Я всего лишь яйцо, но я думаю, что гуру не рекомендуют возиться с sys.path. Благодаря моим экскурсиям мой код стал менее переносимым среди хостов и проектов, появились странные точки разрыва (например, иногда тесты на равенство терпят неудачу, когда один объект имеет класс 'pr1.main.models', а другой 'pr1.test.main .models ') и создал зависимости, которые позже мне было трудно запомнить. Эти усилия были, как правило, атаками на некоторые смутные проблемы управления проектами или рабочими процессами. Решения sys.path не стоили технического долга, который они ввели.

Использование sys.path обычно означает некоторую структурную проблему, с которой я, как новичок, не часто сталкивался, а потом не очень хорошо понимал. Этот материал всегда возникает, когда я спешу сделать что-то еще, но я пытаюсь вспомнить, что правильное выполнение подобных вещей облегчает все остальное в будущем.

Такой инструмент, как virtualenv, мог бы послужить вам лучше. У вас будет среда pr1 с исходным кодом и среда pr1_dev с другим кодом (но с одинаковыми именами модулей). Вы могли бы иметь одно оконечное окно, запускающее одно, а другое - другое. Когда что-то в _dev готово для прайм-тайма, оно может быть перемещено без изменения импорта или ссылок на пространство имен. Конечно, вам придется потратить время на изучение другого инструмента, а не продвигать вперед то, над чем вы работаете.

См. http://pypi.python.org/pypi/virtualenv для виртуальности. Даг Хеллман также написал mkvirtualenv (http://doughellmann.com/2008/05/01/virtualenvwrapper.html), сценарий уровня bash для управления средами.

1 голос
/ 21 ноября 2011

Не проще ли вместо этого использовать два экземпляра одного и того же проекта?

devel.wsgi: 

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

и

production: 

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

Укажите Apache на две соответствующие папки и файлы wsgi.

Таким образом, вы можете использовать всю кодовую базу в управлении версиями, фиксировать для devel и извлекать в производство без необходимости что-либо менять.

...