It is often handy to disable (either temporarily or permanently) South migrations for an app. “Disable” in this context means preventing an app’s migrations from being executed so that the app is managed via
syncdb while in this state. A couple scenarios where this could be useful:
- An app’s migrations are failing somewhere and a developer is stuck trying to install the full schema. It may be in that developer’s interest to just get back to a working state as quickly as possible – especially if someone else is maintaining that app.
- A third-party dependency package ships with migrations. There is often little benefit to running the migrations for a third-party package, and occasionally the migrations won’t apply cleanly if the author doesn’t test the full migration history regularly.
As an example, the django-cms project ships with several dozen migrations. While the authors work hard to maintain the full migration history, accounting for everyone’s specific configuration tweaks across multiple database products isn’t feasible. Some environments can expect to have problems. Unless you are planning on tracking the upstream changes closely, you probably don’t have a need to apply the migrations and can exist happily just letting
syncdb manage the tables.
The South docs mention the use of this technique but I would treat it as an unofficial feature. The way South determines its managed apps is by looking for the presence of a
migrations directory for each app in
INSTALLED_APPS. South also has an override setting that allows you to specify the migrations package directory for your apps. South handles failure while processing this setting by deferring management of the app to
syncdb if the migrations module is not found. By setting the migration module to a bogus path you can leave your migrations directory intact and South won’t manage that app. When you’d like to enable/resume migrations for an app simply remove the reference to the app in the
Follow the example in the South docs if you’d like to disable an app.