id summary reporter owner description type status component version severity resolution keywords cc stage has_patch needs_docs needs_tests needs_better_patch easy ui_ux 27248 Running migrations one-by-one fails after adding django.contrib.sites to INSTALLED_APPS. John Eskew nobody "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 }}} 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." Bug closed contrib.sites 1.8 Normal fixed migrations django_site Unreviewed 0 0 0 0 0 0