Как вернуть и запустить старый проект Django, как это было раньше?

Question

У меня есть старый проект Django, который я не поддерживал, и теперь я хотел бы внести необходимые изменения для работы с текущими версиями Django и сопутствующего программного обеспечения. Я не уверен, что делать с текущей ошибкой; мне кажется, что под зонтиком django.core чего-то нет, но моя установка Django 1.9.2 актуальна:

[2016-02-14 17:23:10 +0000] [4605] [ОШИБКА] Исключение в рабочем процессе:
Traceback (последний вызов был последним):
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/arbiter.py", строка 515, в spawn_worker
    worker.init_process()
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base.py", строка 122, в init_process
    self.load_wsgi()
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base.py", строка 130, в load_wsgi
    self.wsgi = self.app.wsgi()
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/app/base.py", строка 67, в wsgi
    self.callable = self.load()
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/app/djangoapp.py", строка 141, в загрузке
    mod = util.import_module("gunicorn.app.django_wsgi")
  Файл "/usr/lib/python2.7/importlib/__init__.py", строка 37, в файле import_module
    __import__(имя)
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/app/django_wsgi.py", строка 21, в 
    из django.core.management.validation import get_validation_errors
ImportError: нет модуля с именем проверки
Traceback (последний вызов был последним):
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/arbiter.py", строка 515, в spawn_worker
    worker.init_process()
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base.py", строка 122, в init_process
    self.load_wsgi()
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base.py", строка 130, в load_wsgi
    self.wsgi = self.app.wsgi()
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/app/base.py", строка 67, в wsgi
    self.callable = self.load()
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/app/djangoapp.py", строка 141, в загрузке
    mod = util.import_module("gunicorn.app.django_wsgi")
  Файл "/usr/lib/python2.7/importlib/__init__.py", строка 37, в файле import_module
    __import__(имя)
  Файл "/usr/local/lib/python2.7/dist-packages/gunicorn/app/django_wsgi.py", строка 21, в 
    из django.core.management.validation import get_validation_errors
ImportError: нет модуля с именем проверки
[2016-02-14 17:23:10 +0000] [4605] [INFO] Рабочий выходит (pid: 4605)
[2016-02-14 17:23:11 +0000] [4597] [ИНФО] Завершение работы: мастер
[2016-02-14 17:23:11 +0000] [4597] [INFO] Причина: рабочий не загрузился.
root@localhost:~/unixytalk# pip install Django==1.9.2
Требование уже выполнено (используйте --upgrade для обновления): Django==1.9.2 в /usr/local/lib/python2.7/dist-packages

Как я могу перенести свой проект на более новый Django? Как, например, я могу предоставить (или сказать, что он предоставляется) django.core.management.validation?

И если я могу включить еще один архаичный вопрос, что заменяет "python manage.py syncdb" для инициализации базы данных в проекте, о котором может заботиться приложение?

--ОБНОВИТЬ--

Было что-то, от чего я уходил, думая...

Я опубликовал информацию о скриншоте, в котором Gunicorn не работал должным образом, путем импорта из django.core.management.validation, который был помещен туда, очевидно, процессом Gunicorn, и никоим образом не являлся инициативой с моей стороны напрямую взаимодействовать с этот модуль. (Как я уже говорил, я пытался заставить более старую систему работать с более новым кодом. По крайней мере для этого проекта, который ни в каком смысле не включает в себя инициативу использования django.core.management.validation.)

Не слишком тонко для этого, но человек, отвечавший на мой скриншот вставленного вывода, былTL;DR.

Это не я, кто установил темп дляTL;DR; это человек, помогающий мне.

По метрике копирования и вставки в терминах визуализированных символов вTL"выберите все и скопируйте" ;DR - 2412 символов.

Значительные примечания к выпуску, состоящие из 53714 символов, квалифицируются как TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR TL;DR в одной только его последней части, напоминающий статью Джакоба Нильсена о том, почему обучение пользователей не является ответом на проблемы безопасности и система упаковки Nix, которая предназначена для того, чтобы все сохраняли свои собственные необходимые версии своей системы пакетов, вместо того, чтобы все подходило под одну прокрустово ложе любой другой версии, установленной в настоящее время.

Это немного отклоняется от моего первоначального вопроса, за исключением того, что это не так. Мой первоначальный вопрос был задуман так: "Как я могу немного посыпать пиксельную пыль и реанимировать довольно простой старый проект Django?" Теперь все выглядит примерно так: "Тот факт, что я больше не могу выполнять то, что оставил как рабочий проект, является верхушкой айсберга. Учитывая, что я достойный разработчик Django, но не супер-ориентированный специалист по Django, и я работаю с Во многих технологиях битрот выглядит как источник большой боли ".

Хорошо; достаточно жалоб, хотя я подозреваю, что в этом есть пост программистов.

Answer 1

1) Чтобы портировать на более новые версии Django, я прочитал бы каждый набор замечаний к выпуску от версии, с которой вы начали, до версии, которую вы собираетесь использовать. Обязательно прочтите примечания к выпуску Django 1.9, особенно внимательно читая об устаревших, несовместимых назад и удаленных функциях в нижней части.

2) Чтобы проверить, если django.core.management.validation при условии, что вы можете сделать try/except вокруг вашего импорта:

try:
    from django.core.management.validation import get_validation_errors
    validation_errors_imported = True
except ImportError:
    get_validation_errors = None
    validation_errors_imported = False

3) Наконец, вы больше не будете бежать python manage.py syncdb, Начиная с Django 1.7 python manage.py migrate, Удачи!