Running migrations one-by-one fails after adding django.contrib.sites to INSTALLED_APPS.

[John Eskew]

An application we've written added django.contrib.sites to its INSTALLED_APPS. In the same release, other migrations were generated that needed to be applied. The dependency-ordered migrations list at this point pre-migration follows:

migrations:
- [taggit, 0002_auto_20150616_2121]
- [course_metadata, 0017_auto_20160815_2135]
- [course_metadata, 0018_auto_20160815_2252]
- [sites, 0001_initial]
- [django_comments, 0001_initial]
- [django_comments, 0002_update_user_email_field_length]
- [django_comments, 0003_add_submit_date_index]
- [publisher_comments, 0001_initial]

We then attempted to run these migrations one-by-one via python ./manage.py <app> <migration> commands. (Why? To better record which migrations succeeded, which one failed, and which migrations remain unapplied, since this migration process runs in an automated pipeline.) The first specific app/migration migrate failed with a stack nearly the same as the one here:

https://code.djangoproject.com/ticket/24524#comment:12

The problem is that the sites code assumed that after being added to INSTALLED_APPS, a python ./manage.py migrate command would be run to execute all migrations together - and *then* catch a post-migrate signal which calls create_default_site. Running individual migrations does not work when an application is in this state.

It looks like some code is in place to attempt to prevent this error, but it's either incorrect or not working:

​https://github.com/django/django/blob/stable/1.8.x/django/contrib/sites/management.py#L12-L18

The workaround: Issue a python ./manage.py migrate command to exit this state. However, the workaround shouldn't be necessary.

[Tim Graham]

I believe this is fixed in Django 1.10 by 61a16e02702fff4665969388f3b61af8cb1a20ae. If not, please reopen.