Django 1.7 + Django CMS — удалить файлы миграции из моего репозитория или включить в репозиторий virtualenv?

Я использую git для управления версиями проекта Django 1.7 + Django CMS 3.0.6.

В ходе создания различных приложений и т. д. я получаю множество файлов миграции. Файлы миграции в настоящее время включены в мой репозиторий git.

До сих пор я старался не включать виртуальные файлы env напрямую в репозиторий, так как это кажется довольно запутанным и избыточным. Вместо этого я до сих пор включал в репозиторий файл требований pip и использовал его для воссоздания виртуальной среды при необходимости.

Однако недавно я обнаружил, что выбор включения файлов миграции в репозиторий, по-видимому, требует включения в репозиторий и всех виртуальных файлов env. Я говорю это, потому что при развертывании моего проекта на производственном сервере и попытке запустить любую из команд базы данных (syncdb, makemigrations или migrate) через python manage.py я получаю сообщение об ошибке:

KeyError: u"Migration image_gallery.0001_initial dependencies reference nonexistent parent node (u'cms', u'0004_auto_20141108_1256')"

тогда как на моей локальной машине такой ошибки не возникает даже после удаления базы данных.

Я отследил источник этой ошибки до того факта, что виртуальный env на моей локальной машине имеет ссылку на «0004_auto_20141108_1256» (внутри пакета django-cms — кажется, что некоторая информация о миграции cms записывается непосредственно внутри самого виртуального каталога env) в то время как в производственной среде нет - поскольку производственный venv создает полный файл требований к пипсу. Поэтому две виртуальные среды не совсем совпадают, хотя все сторонние библиотеки одинаковы. В настоящее время я не включаю venv в свой репозиторий git.

Итак, как я вижу, у меня есть два варианта:

1. include the virtual env in my git repo
2. drop the migration files from git

Какой вариант лучше и почему - или есть третий еще лучший способ?

Недостатком № 1 является ненужное раздувание. Недостатком варианта № 2 является потеря истории миграции, которую можно было бы сохранить.


git django django-migrations django-cms django-1.7
person David Simic    schedule 28.12.2014    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Вы никогда не совершаете виртуальную среду, это побеждает цель; вы просто добавляете ненужный контент в git.

Вместо этого заморозьте требования и зафиксируйте файл:

pip freeze > requirements.txt

Установите пакеты на сервер:

pip install -r requirements.txt
person Pran    schedule 28.12.2014
comment
В настоящее время я следую этому подходу, однако, как указано в моем вопросе, результирующая виртуальная среда не идентична моей локальной, поскольку миграции, выполняемые на моей локальной машине, фактически изменяют файлы в самой виртуальной среде (внутри django-cms, это это характерно для django cms?) таким образом, который не отражен в файле требований. Поэтому при попытке установить новую установку в рабочей среде я получаю ошибки при попытке настроить базу данных из-за этого несоответствия в виртуальных окружениях (см. вопрос для получения более подробной информации). - person David Simic; 28.12.2014
comment
Извините, надо было дважды прочитать, а написать один :). Я посмотрел проект на github, и мне показалось, что у кого-то еще была похожая проблема. Кажется, в v3.0.7 есть исправление. Я не использовал django-cms, поэтому не могу комментировать, решит ли это вашу проблему. github.com/divio/django-cms/issues/3572 - person Pran; 28.12.2014
comment
Пран: посмотри мой ответ, надеюсь, он поможет с этой проблемой. Проблема в моем случае на самом деле не проблема с django-cms, а проблема с конфигурацией (хотя я подозреваю, что некоторые из рекомендаций, которые я нашел в Интернете по настройке cms, могли привести к моей проблеме). - person David Simic; 29.12.2014

arrow_upward
0
arrow_downward

Проблема в моем файле django settings.py:

MIGRATION_MODULES = {
    'cms': 'cms.migrations_django',
    'menus': 'menus.migrations_django',
    'djangocms_file': 'djangocms_file.migrations_django',
    ...
}

Мне пришлось ввести вышеизложенное, чтобы заставить django-cms 3.0.6 работать с django 1.7, что является следствием того факта, что миграции в django 1.7 больше не выполняются с помощью South, поскольку django 1.7 теперь имеет собственную систему миграции, а cms 3.0 .6. по-прежнему ожидает, что миграция будет управляться South по умолчанию.

Однако результат приведенной выше конфигурации заключается в сохранении миграций по описанным выше путям, которые в моем случае указывали прямо на виртуальную среду. Таким образом, информация о переносе сохранялась в виртуальном каталоге env, что приводило к проблемам при развертывании в рабочей среде.

Чтобы исправить это, я изменил структуру каталогов моего проекта, включив в нее папку с именем «миграции»:

myproject/manage.py
myproject/migrations/
myproject/myproject/
...

И изменил конфигурацию так:

MIGRATION_MODULES = {
    'cms': 'migrations.cms.migrations_django',
    'menus': 'migrations.menus.migrations_django',
    'djangocms_file': 'migrations.djangocms_file.migrations_django',
    ...
}

Это приводит к тому, что теперь все файлы миграции хранятся в самом проекте django (и, соответственно, в репозитории git). Поскольку информация о миграции больше не находится в каталоге виртуального окружения, больше нет причин рассматривать довольно непривлекательную возможность включения виртуального окружения в репозиторий.

person David Simic    schedule 28.12.2014