django 1.7 migrations changes detected for socialaccount and socialapps

[YAmikep]

When you run python manage.py migrate a second time, it says that there are changes.
Running python manage.py makemigrations, the changes are actually for the socialaccount and socialapp apps.
The migration file is written into the site-packages directory:
/venv/lib/python2.7/site-packages/allauth/socialaccount/migrations/0002_auto_20141022_1 424.py

I saw in the code that the changes are about the providers. The change will be detected everytime the list of providers change.https://github.com/pennersr/django-allauth/blob/master/allauth/socialaccount/migrations/0001_initial.py#L21

Is that normal?
Thanks

(venv)my_project@vagrant-ubuntu-trusty-64:/projects/my_project/webapp$ python manage.py migrate
Operations to perform:
  Synchronize unmigrated apps: django_rq, ordered_model, allauth, django_extensions
  Apply all migrations: account, sessions, admin, sites, my_project_core, contenttypes, auth, socialaccount
Synchronizing apps without migrations:
  Creating tables...
  Installing custom SQL...
  Installing indexes...
Running migrations:
  No migrations to apply.
  Your models have changes that are not yet reflected in a migration, and so won't be applied.
  Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
(venv)my_project@vagrant-ubuntu-trusty-64:/projects/my_project/webapp$ python manage.py makemigrations
Migrations for 'socialaccount':
  0002_auto_20141022_1424.py:
    - Alter field provider on socialaccount
    - Alter field provider on socialapp

Here is the migration file generated

# -*- coding: utf-8 -*-
from __future__ import unicode_literals
from django.db import models, migrations

class Migration(migrations.Migration):
    dependencies = [
        ('socialaccount', '0001_initial'),
    ]

    operations = [
        migrations.AlterField(
            model_name='socialaccount',
            name='provider',
            field=models.CharField(max_length=30, verbose_name='provider'),
        ),
        migrations.AlterField(
            model_name='socialapp',
            name='provider',
            field=models.CharField(max_length=30, verbose_name='provider'),
        ),
    ]

[yourcelf]

Django recognizes changes in the choices for a field as a change requiring migration. (See #22837 for an explanation). Since the choices are determined dynamically by the particular social auth providers you have enabled in settings, unless you have exactly the same list the maintainers have, Django will see fit to create a migration for you.

[pennersr]

While indeed somewhat unexpected, the ticket referred by @yourcelf clearly states this is "by design".

[pykler]

SocialAccount instances will rarely be created by hand, usually created by allauth directly. I would say removing the choices all together is probably the solution for this one, since there is little benefit of having the choices there in the first place, but the fact that it is dynamic causes issues with migrations (which is a gotcha that will get everyone).

[pykler]

The temporary solution I did while this is being figured out is creating my own migrations for socialaccount by adding this to the settings file:

MIGRATION_MODULES = {
    'socialaccount': 'socialaccount_overrides.migrations',
}

[pifantastic]

The last comment on https://code.djangoproject.com/ticket/22837 links to issue https://code.djangoproject.com/ticket/13181 which added support for passing a callable to choices=. Which, if I understand correctly, means this problem can be solved like so:

diff --git a/allauth/socialaccount/models.py b/allauth/socialaccount/models.py
index 08be06b..5352afd 100644
--- a/allauth/socialaccount/models.py
+++ b/allauth/socialaccount/models.py
@@ -37,7 +37,7 @@ class SocialApp(models.Model):

     provider = models.CharField(verbose_name=_('provider'),
                                 max_length=30,
-                                choices=providers.registry.as_choices())
+                                choices=providers.registry.as_choices)
     name = models.CharField(verbose_name=_('name'),
                             max_length=40)
     client_id = models.CharField(verbose_name=_('client id'),

However, https://code.djangoproject.com/ticket/13181 is going into Django 1.8, and I can't tell if it will be backported to Django 1.7.

[johanneswilm]

Any updates on this? I am seeing the same in Django 3.1. @pennersr

[johanneswilm]

The same explanation for how to avoid this seems also to be given here: http://tech.yunojuno.com/pro-tip-django-choices-and-migrations .

[efojs]

Came here because something caused changes in allauth models requiring migrations.
I'd happy to make and migrate, but I can not push them, can I? (it seems to be not OK requiring makemigrations on remote)
I even don't get what caused them — could you guys give any hint on that, please?

Only things I did with auth — installed django-sesame and unregistered allauth models from admin

makemigrations created the following two:

# account/migrations
class Migration(migrations.Migration):

    dependencies = [
        ('account', '0002_email_max_length'),
    ]

    operations = [
        migrations.AlterField(
            model_name='emailaddress',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
        migrations.AlterField(
            model_name='emailconfirmation',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
    ]

# socialaccount/migrations
class Migration(migrations.Migration):

    dependencies = [
        ('socialaccount', '0003_extra_data_default_dict'),
    ]

    operations = [
        migrations.AlterField(
            model_name='socialaccount',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
        migrations.AlterField(
            model_name='socialapp',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
        migrations.AlterField(
            model_name='socialtoken',
            name='id',
            field=models.BigAutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID'),
        ),
    ]

update:

• allauth/account/models.py in my copy and in repo are identical: https://www.diffchecker.com/KgCa3BDY
• my CustomUser hasn't change since the beginning:

class CustomUser(AbstractUser):
    pass

---

Update:
I guess this is connected with Customizing type of auto-created primary keys in Django 3.2:

When defining a model, if no field in a model is defined with primary_key=True an implicit primary key is added. The type of this implicit primary key can now be controlled via the DEFAULT_AUTO_FIELD setting and AppConfig.default_auto_field attribute.
Maintaining the historical behavior, the default value for DEFAULT_AUTO_FIELD is AutoField. Starting with 3.2 new projects are generated with DEFAULT_AUTO_FIELD set to BigAutoField.

Addressed in #2829 PR