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

Question

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

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

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

Тем не менее, я недавно обнаружил, что выбор включения файлов миграции в репо требует, в частности, всех виртуальных файлов env в репо. Я говорю это потому, что при развертывании моего проекта на сервере и пытается запустить любой из команд БД (SyncDB, makemigrations или мигрировать) с помощью питона 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), в то время как в производственной среде нет - поскольку производственный центр создает подробный файл требований к требованиям. Следовательно, два виртуальных envs точно не совпадают, хотя все сторонние библиотеки одинаковы. В настоящее время я не включаю в себя venv в моем git repo.

Так как я вижу это у меня есть два варианта:

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

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

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

Answer 1

проблема в моем Джанго 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 больше не выполняется с Югом, поскольку у django 1.7 теперь есть собственная миграционная система, а cms 3.0.6. по-прежнему ожидает, что миграция будет управляться Югом по умолчанию.

Однако эффект вышеуказанной конфигурации заключается в сохранении миграций в описанных выше путях, которые в моем случае указывали прямо на виртуальный 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 repo). Поскольку информация о миграции больше не находится в каталоге виртуального env, больше нет причин рассматривать довольно непривлекательную возможность включения виртуального env в репо.

Answer 2

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

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

pip freeze > requirements.txt 

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

pip install -r requirements.txt