South migration error: NoMigrations exception for django.contrib.auth

Question

I have been using South on my project for a while, but I recently did a huge amount of development and changed development machine and I think something messed up in the process. The project works fine, but I can't apply migrations. Whenever I try to apply a migration I get the following traceback:

danpalmer:pest Dan$ python manage.py migrate frontend
Traceback (most recent call last):
  File "manage.py", line 11, in <module>
    execute_manager(settings)
  File "/Library/Python/2.6/site-packages/django/core/management/__init__.py", line 362, in execute_manager
    utility.execute()
  File "/Library/Python/2.6/site-packages/django/core/management/__init__.py", line 303, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/Library/Python/2.6/site-packages/django/core/management/base.py", line 195, in run_from_argv
    self.execute(*args, **options.__dict__)
  File "/Library/Python/2.6/site-packages/django/core/management/base.py", line 222, in execute
    output = self.handle(*args, **options)
  File "/Library/Python/2.6/site-packages/South-0.7-py2.6.egg/south/management/commands/migrate.py", line 102, in handle
    delete_ghosts = delete_ghosts,
  File "/Library/Python/2.6/site-packages/South-0.7-py2.6.egg/south/migration/__init__.py", line 182, in migrate_app
    applied = check_migration_histories(applied, delete_ghosts)
  File "/Library/Python/2.6/site-packages/South-0.7-py2.6.egg/south/migration/__init__.py", line 85, in check_migration_histories
    m = h.get_migration()
  File "/Library/Python/2.6/site-packages/South-0.7-py2.6.egg/south/models.py", line 34, in get_migration
    return self.get_migrations().migration(self.migration)
  File "/Library/Python/2.6/site-packages/South-0.7-py2.6.egg/south/models.py", line 31, in get_migrations
    return Migrations(self.app_name)
  File "/Library/Python/2.6/site-packages/South-0.7-py2.6.egg/south/migration/base.py", line 60, in __call__
    self.instances[app_label] = super(MigrationsMetaclass, self).__call__(app_label_to_app_module(app_label), **kwds)
  File "/Library/Python/2.6/site-packages/South-0.7-py2.6.egg/south/migration/base.py", line 88, in __init__
    self.set_application(application, force_creation, verbose_creation)
  File "/Library/Python/2.6/site-packages/South-0.7-py2.6.egg/south/migration/base.py", line 159, in set_application
    raise exceptions.NoMigrations(application)
south.exceptions.NoMigrations: Application '<module 'django.contrib.auth' from '/Library/Python/2.6/site-packages/django/contrib/auth/__init__.pyc'>' has no migrations.

I am not that experienced with South and I haven't met this error before. The only helpful mention I can find online about this error is for pre-0.7 I think and I am on South 0.7. I ran 'easy_install -U South' just to make sure.

Solution 1

I solved the problem.

Obviously, you can't use South to do the migrations for the apps that are part of Django, like 'auth' so I didn't know why it was trying to.

I realised that for a while I had another app within my project called auth. I must have tried to migrate this at some point before renaming it and therefore messed it all up.

I removed the migration history entries from the database for that app and everything was fine.

Solution 2

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.

Solution 3

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)

Solution 4

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.

Solution 5

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']

View more solutions

Comments

[Jyrsa]

Ran into same with messages app just today.

[mrooney]

You CAN use South for apps that are part of Django like auth, and it does sometimes make sense. Please see my answer below. I'm not sure what to do when the accepted answer isn't correct, maybe you can edit your answer to contain my correct answer?

[Prince Paul]

Note the "reset" command was replaced with "flush" in Django 1.5, although flush doesn't work with individual tables. For that you'll need to use this port of the old reset: github.com/gregmuellegger/django-reset

[akozin]

Thanks, it helped me too.

[andyzinsser]

This is also a quick fix for when you want to delete just a single apps migrations instead of reseting / flushing all of south.

[gipi]

For me was an incoherent state between registered migrations into the database and the removal of the migrations directory. Adding a migrations and its __init__.py solved the problem.

[NeoVe]

Awesome this solved my issue, although i'm not the OP hehe cheers

[Rockallite]

I was in an opposite situation. I deleted the *.py migration files, leaving the *.pyc versions alone. The South or Django 1.7+ migration framework doesn't recognize *.pyc migration files. Also, check MIGRATION_MODULES setting in Django settings module.