Order of "choices" on CharField randomly changing forcing new migrations despite no changes.

[Karl]

I have a field attachment_type in a class that uses

TYPE_CHOICES = {
        ("image", "Image"),
        ("document", "Document"),
        ("audio", "Audio"),
        ("video", "Video"),
    }

Every makemigrations call generates a new migration for that field:

migrations.AlterField(
            model_name="genericattachment",
            name="attachment_type",
            field=models.CharField(
                choices=[
                    ("audio", "Audio"),
                    ("document", "Document"),
                    ("video", "Video"),
                    ("image", "Image"),
                ],
                default="image",
                max_length=10,
            ),
        ),

I noticed that the order of the choices in the migration changes every time. It doesn't seem to have a consistent method to compare the set of tuples properly and so it generates a new migration every time. I have not yet observed that it even accidentally collides in a way that does not generate a new one.

[Natalia Bidart]

Hello WoosterInitiative, thank you for taking the time to create this report.

This ticket is, strictly speaking, a duplicate of #26609, which was closed as wontfix for the reasons detailed in the ticket:26609#comment:3. But I'm happy to say that you can also workaround this issue by defining a callable for your choices (see #24561 and ​release notes), and this will avoid having migrations being generated because the order of the choices changed.

[Claude Paroz]

I don't think that a set() is a supported data structure for model field choices. Maybe we should replace A mapping or iterable in the format described below by A mapping or sequence in the format described below in ​the docs?

[Natalia Bidart]

Replying to Claude Paroz:

I don't think that a set() is a supported data structure for model field choices. Maybe we should replace A mapping or iterable in the format described below by A mapping or sequence in the format described below in ​the docs?

Code wise, we really do not mind that these are sets... Do you see a concrete issue with using sets? (other than dropdowns or options being shown in a random order).

[Karl]

Replying to Claude Paroz:

I don't think that a set() is a supported data structure for model field choices. Maybe we should replace A mapping or iterable in the format described below by A mapping or sequence in the format described below in ​the docs?

Figured this out. It isn't explicitly *not* allowed, but it causes the issue I reported. If it is going to be allowed in the docs explicitly, migrations should handle it well.

Beyond that, I don't know why one would need a set(). Pretty sure I was just combining a couple of sections of the docs when I wrote it because I can't ever remember the specific syntax and made a mistake.

Curious if a check could be created to prevent my (and other's) future confusion?