Django 1.7 warning - You have unapplied migrations

[mtirsel]

Current migration for Django 1.7 is missing related_name argument for the UserSocialAuth.user field. If calling makemigrations command, this creates migration 0002 in social default app. AFAIK related_name shouldn't do any changes in database, so it should be safe to just add related_name=b'social_auth' argument to the CreateModel fields in 0001_initial.py.

[stevejalim]

@mtirsel I'm experiencing something similar, in that running makemigrations to port a 1.6 project to 1.7.1 generates a bogus 0002 migration on the default app, which when applied by the test runner causes any integration tests that use python-social-auth to explode. Why? Take a look at what the 0002 contains:

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations


class Migration(migrations.Migration):

    dependencies = [
        ('default', '0001_initial'),
    ]

    operations = [
        migrations.DeleteModel(
            name='Association',
        ),
        migrations.DeleteModel(
            name='Code',
        ),
        migrations.DeleteModel(
            name='Nonce',
        ),
        migrations.AlterUniqueTogether(
            name='usersocialauth',
            unique_together=None,
        ),
        migrations.RemoveField(
            model_name='usersocialauth',
            name='user',
        ),
        migrations.DeleteModel(
            name='UserSocialAuth',
        ),
    ]

Yep, that's right, it just drops all the models, which implies:

1. that either the Django migration code is not finding the model, but finding the 0001 migration and thinking all the models have been junked.

or

2. something about p-s-a isn't quite set up right for 1.7.1 (eg explicit app labels -- apps with nested models and lacking explicit app labels seem to fox the migration discovery code)

Does your experience match this, @mtirsel? Does your 0002 (in site-packages/social/migrations) look like mine?

Cheers
Steve

[stevejalim]

Update (and partic one for @omab), I just forked p-s-a and...

1. tried the updated 0001 migration that mentions the related_name change in @mtirsel's message (https://github.com/omab/python-social-auth/blob/master/social/apps/django_app/default/migrations/0001_initial.py#L78). This did not prevent a deadly 0002 being generated.

2. I added an explict app_label value to all of the models in python-social-auth/social/apps/django_app/default/models.py. ie, in Meta, I added app_label="default". This DID prevent the creation of a deadly 0002.

I'm going to ride with our fork for a while (https://github.com/yunojuno/python-social-auth/) before offering up a PR, but if you agree that it make sense, @omab, let me know and I'll issue a PR.

Cheers
Steve

[mtirsel]

Any progress? This is causing a lot of problems in automated builds/deployments and is easy to fix.

[stevejalim]

@mtirsel Have you tried my fork, above? If it works for you in your automated builds, too, I'll issue a pull request to @omab

[bendavis78]

See above pull request. The fix was to remove the b prefix on the default_value for the extra_data field. This bug appears to have been introduced by 587da25.