Feature proposal: add support for south_migrations submodule so South migrations can live alongside Django 1.7 migrations

[Trey Hunner]

Some open source Django libraries will not able to require users to switch to South2 immediately after the Django 1.7 release.

To allow both the new 1.7 migrations and existing South migrations to live side-by-side more easily, I propose that `appname.south_migrations` be checked for migrations in addition to `appname.migrations`.  This will allow apps that need to support both migrations to do so with minimal pain for developers or users.

This proposal would make it unnecessary for authors of packages that plan to support both migrations to use workaround solutions such as raising an exception for South users (e.g. as noted in this blog post: http://treyhunner.com/2014/03/migrating-to-django-1-dot-7/) or using a __path__ hack (e.g. https://github.com/treyhunner/django-email-log/pull/8).

What do you think of this proposal?

[Andrew Godwin]

I've discussed this proposal with a few core devs here as well and the consensus is that it generally makes sense, so I'll likely be putting it into the next release. Would appreciate any extra feedback from people on here, though.

Andrew

--
You received this message because you are subscribed to the Google Groups "South Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to south-users...@googlegroups.com.
To post to this group, send email to south...@googlegroups.com.
Visit this group at http://groups.google.com/group/south-users.
For more options, visit https://groups.google.com/d/optout.

[Jon Cotton]

Chiming in to add another vote of interest. I'm a maintainer of several packages with migrations and I'd like a non-hack way to support older Djangos along with 1.7. The South 2 solution is great where there is one set of migrations, native to Django 1.7 and usable via South 2 for older versions. But a new South 0.x is a fine solution too. Trey Hunner proposes a quite reasonable option where `south_migrations` coexist with `migrations`. All we need is a South 0.x that uses this scheme.

Telling upgraders that they must specify `SOUTH_MIGRATION_MODULES` in settings.py, while pretty painless, is a break of backward compatibility. Pip-requiring a new version of South is better. If the end user didn't want to update South, then they could still use the settings.py config.

Most of all, I'd like to avoid the situation of "choosing poorly" where I ship something that is incompatible with whatever solution South does implement.

[Andrew Godwin]

Yep, I'm planning to add the south_migrations support in the next release, once I get Django 1.7 un-release-blocked (it's a simple change).

South 2 may or may no longer be possible due to recent advances in Django 1.7 migrations technology, so this might become the only way to have parallel migration sets. We'll see.

Andrew

--