Версия контролирует южные миграции в virtualenv

Question

У меня есть сайт Django, помещенный в папку site/. Это под контролем версий. Я использую Юг для миграции схем и данных для своих приложений. Специфичные для сайта приложения находятся в папке site/, поэтому все они контролируются версиями вместе со своими миграциями.

Я управляю virtualenv, чтобы компоненты сторонних производителей были сухими и безопасными. Я устанавливаю пакеты через PyPI. Список установленных пакетов заморожен в файле require.txt, поэтому их можно легко установить в другой среде. Virtualenv не под VCS. Я думаю, что это хороший способ, если virtualenv можно легко удалить и восстановить в любое время. Если мне нужно протестировать мой сайт, например, с использованием другой версии интерпретатора Python, просто активируйте другую virtulalenv.

Я бы хотел использовать Юг для сторонних пакетов. Здесь возникает проблема. Скрипты миграции хранятся в папке приложения, поэтому они находятся вне репозитория моего сайта. Но я хочу, чтобы скрипты миграции находились под контролем версий, чтобы я мог запускать их и на разных этапах.

Я не хочу управлять версиями всего virtualenv, кроме сценариев миграции для сторонних приложений. Как я могу решить этот конфликт? Есть ли какое-то неправильное представление в моем сценарии?

Answer 1

Параметр SOUTH_MIGRATION_MODULES позволяет вам размещать модули миграции для указанных приложений там, где вы хотите их (т.е. внутри дерева проекта).

Answer 2

Я думаю, это зависит от вашей системы контроля версий.Я рекомендую использовать разреженное дерево, которое управляет только папками миграции различных пакетов.Здесь я вижу две альтернативы:

1. Создайте действительно разреженное дерево для всех пакетов, которое вы проверяете перед созданием virtualenv.Затем заполните virtualenv, поместив содержимое в существующие папки.

2. Соберите все миграции в отдельный репозиторий с папками для каждого проекта / внешней зависимости.Проверьте это в virtualenv и создайте символические ссылки, связывающие каждый проект со своей папкой миграции.

В любом случае я считаю, что вы можете организовать миграцию как отдельный проект, так что вы можете установить его так же, как и все остальное (easy_install / pip / любой другой).