[Django]-South migration error: NoMigrations exception for django.contrib.auth

Leaving this here for future googlers

I recently ran into this exceptions with one of my own apps today, not a contrib one.

After a bit of head-scratching I noticed that somehow the file …

 app/migrations/__init__.py

… had been deleted, which means python cant import the dir as a module etc etc.

I just ran into this after swithcing branches and app versions, and decided to remove the app that now had no migrations from the south_migrationhistory table

./manage.py dbshell

mysql> SELECT * FROM south_migrationhistory WHERE app_name = 'social_auth';

104 | social_auth | 0001_initial...                                                                   
105 | social_auth | 0002_auto__add_unique_nonce...


mysql> DELETE FROM south_migrationhistory WHERE app_name = 'social_auth';
Query OK, 2 rows affected (0.00 sec)

I also had the same problem, and at the end I fixed this by deleting all rows from south_migrationhistory table and run the following command from terminal.

python manage.py reset south

This answer explain about how to reset south migration history.

Edit:

From Django 1.5 onwards reset command won’t work. Instead you have to use flush.

python manage.py flush

To understand more about what flush will do read this stackoverflow answer.

I also had the same issue, however this happened to the root application. I discovered that this was due to an empty models.py in my project root from earlier development. I suspect this issue may arise for project applications also.

You can do migrations on built-in modules, and it definitely makes sense for data migrations, for example, truncating all usernames, removing invalid emails, et cetera.

In the case of a User from django.contrib.auth.models, simply use: orm[‘auth.User’]

I got the same error, but not for a django module, but for a module that was part of my virtualenv. I didn’t get how south could have done a migration for that module, since it really didn’t have any migrations. Then I remembered I had copied the database from an test env that was supposed to be the same. But it turned out the other env had a slightly different version of the module which did have a migration.
I ended up deleting the offending row from the south migrationhistory (since it was a test env anyway).

I had a similar problem with django.contrib.admin not letting me run my migrations. I solved it by disabling django.contrib.admin in settings.INSTALLED_APPS