Django custom User shoots an import issue at runtime when syncing db

Question

I have a custom User model defined in app.models. It is also correctly defined in the AUTH_USER_MODEL setting as app.User. When I run the site, everything works perfectly.

However, when I run ./manage.py syncdb --migrate it breaks with the following traceback:

Traceback (most recent call last):
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 222, in run_from_argv
    self.execute(*args, **options.__dict__)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 255, in execute
    output = self.handle(*args, **options)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 386, in handle
    return self.handle_noargs(**options)
  File ".virtualenv/lib/python2.7/site-packages/south/management/commands/syncdb.py", line 103, in handle_noargs
    management.call_command('migrate', **options)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/__init__.py", line 161, in call_command
    return klass.execute(*args, **defaults)
  File ".virtualenv/lib/python2.7/site-packages/raven/contrib/django/management/__init__.py", line 37, in new_execute
    return original_func(self, *args, **kwargs)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 255, in execute
    output = self.handle(*args, **options)
  File ".virtualenv/lib/python2.7/site-packages/south/management/commands/migrate.py", line 111, in handle
    ignore_ghosts = ignore_ghosts,
  File ".virtualenv/lib/python2.7/site-packages/south/migration/__init__.py", line 233, in migrate_app
    migrator.load_initial_data(target, db=database)
  File ".virtualenv/lib/python2.7/site-packages/south/migration/migrators.py", line 224, in load_initial_data
    call_command('loaddata', 'initial_data', verbosity=self.verbosity, database=db)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/__init__.py", line 161, in call_command
    return klass.execute(*args, **defaults)
  File ".virtualenv/lib/python2.7/site-packages/raven/contrib/django/management/__init__.py", line 37, in new_execute
    return original_func(self, *args, **kwargs)
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 254, in execute
    self.validate()
  File ".virtualenv/lib/python2.7/site-packages/django/core/management/base.py", line 285, in validate
    raise CommandError("One or more models did not validate:\n%s" % error_text)
CommandError: One or more models did not validate:
auth.user: Model has been swapped out for 'app.User' which has not been installed or is abstract.

When I run ./manage.py syncdb --migrate app everything runs correctly, so I don't get what's up here. Does anyone have a clue?

EDIT: Order of my installed apps:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.admin',
    'django.contrib.webdesign',
    'django.contrib.staticfiles',
    'djcelery',
    'app',

    'babeldjango',
    'debug_toolbar',
    'template_timings_panel',
    'devserver',
    'django_extensions',
    'djrill',
    'facebook_tag',
    'gunicorn',
    'haystack',
    'markitup',
    'modeltranslation',
    'raven.contrib.django',
    'reversion',
    'rosetta',
    'sorl.thumbnail',
    'south',
    'statictastic',
    'storages',
    'twitter_tag',
    'zebra',
    'djcelery',
    'djmoney_rates'
)

EDIT 2: The issue seems to be arising from the migrations run in third party apps. If I comment out those apps that have migrations, everything goes smoothly. I guess this is also expected since ./manage.py migrate app works fine, but ./manage.py migrate (which runs migrations for all apps) doesn't. And building off of that information and the trace, it seems that my app's models are simply not available when the third party apps' migrations are being run.

Answer 1

Had the same problem, solved it migrating from South 0.8.3 to South 0.8.4

Saw the solution here: http://south.aeracode.org/ticket/1179