Default application used in startapp has an empty migration package

[Iacopo Spalletti]

Default application used in startapp has an empty migration package, which results in the MigrationLoader treating it as an application which has migrations (​https://github.com/django/django/blob/stable/1.7.x/django/db/migrations/loader.py#L72). This may trigger errors when trying to resolve model dependencies: say for example in a newly created application with a custom user model and an existing application which uses the custom user model and that already has migrations.

For a real case of this happening: ​https://github.com/divio/django-cms/issues/3436#issuecomment-55913624

Any specific reason for shipping the migration directory in the template application?

[Florian Apolloner]

Any specific reason for shipping the migration directory in the template application?

New apps are supposed to be migration ready by default, the module serves as marker for that.

This may trigger errors when trying to resolve model dependencies: say for example in a newly created application with a custom user model and an existing application which uses the custom user model and that already has migrations.

Examples? Preferably simple ones which don't involve django-cms :)

[Iacopo Spalletti]

Replying to apollo13:

Any specific reason for shipping the migration directory in the template application?

New apps are supposed to be migration ready by default, the module serves as marker for that.

This may trigger errors when trying to resolve model dependencies: say for example in a newly created application with a custom user model and an existing application which uses the custom user model and that already has migrations.

Examples? Preferably simple ones which don't involve django-cms :)

This sample project ​https://github.com/jsma/cmstest should be simple enough to run. It depends on django CMS but it's just an installable dependency.

(cmstest-user)yakky@andalu: /srv/repo/cmstest/cmstest $ ../manage.py makemigrations accounts

django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'cms.PageUser'>]
This can happen if you are inheriting models from an app with migrations (e.g. contrib.auth) in an app with no migrations; see ​https://docs.djangoproject.com/en/1.7/topics/migrations/#dependencies for more

By removing the empty migrations directory in cmstests.accounts the migration is created correctly and everything applies cleanly.

[Tomáš Ehrlich]

Replying to apollo13:

Any specific reason for shipping the migration directory in the template application?

New apps are supposed to be migration ready by default, the module serves as marker for that.

Is it really necessary to make new apps "migration ready"? Especially now, when we have brand new migrations which can handle migration of existing models better than South. Also, with new app loading, apps no longer require to have models.py and live completely without any models.

[Collin Anderson]

The migrations folder tells django's new ./manage.py makemigrations to create an initial migration for that app. Otherwise makemigrations will assume it's an old, unmigrated app and ignore it. Once we require migrations for all apps, we could delay creating that folder until makemigrations is run the first time.

Looking at the ticket on django-cms, this looks like the actual problem to me:

When I do ./manage.py makemigrations accounts I get the following error (this is on an new, empty database, no other migrations have been applied yet.):
django.db.migrations.state.InvalidBasesError: Cannot resolve bases for [<ModelState: 'cms.PageUser'>]
If I temporarily comment out the cms apps from INSTALLED_SETTINGS, I can create the initial migration, then uncomment the cms apps and run the full ./manage.py migrate without any problems.

[Tim Graham]

Another way I could get the initial migration to be created is to comment out AUTH_USER_MODEL = 'accounts.User' in settings.py. It seems to me there's a bug here or else we need to provide more guidance on how to resolve the issue. Adding Andrew to get his input.

[Andrew Godwin]

Well, the bug mentioned above is definitely not to do with the empty migrations folder (which, as was correctly posted, is so new apps are not ignored by makemigrations - we can remove the empty folder when we deprecate the syncdb-style path in 2.0, as at that point makemigrations can assume everything has migrations).

The root of the cause here seems to be the custom user model, which as the docs mention in several places, must be made in the first migration of an app. makemigrations is meant to have code that ignores this style of error while it's running (as you may be doing it to make the migration for said user model), but I've not seen that result in this error before - usually it manifested as a graph dependency error (as the migration depending on the custom user model would have a dependency on an app with no migrations).

I'm not sure what the Django bug is here - the original reporter or people more familiar with CMS will need to dig down and either give a simple project that can reproduce the issue (i.e. one without the intricacies of CMS) or work out why it's trying to import PageUser when, as far as the CMS bug says, it's someone's own personal custom user.

[Iacopo Spalletti]

Thanks andrewgodwin to clarify this.
Actually PageUser is a django CMS model.
In the end we need to make sure that our users will create migrations for their custom user models before enabling the CMS (or before declaring the AUTH_USER_MODEL) because otherwise they will experience dependencies issues.