Generate migration dependencies in a deterministic order

[Dakota Hawkins]

From ​this google groups discussion:

We haven't really deployed yet, so generally to make migrations we're deleting existing migration files and re-running makemigrations.

We have two apps, and one of them depends on the other as well as django.contrib.auth. In that app's migrations the dependencies often swap order seemingly indeterminately.

The resulting migration includes either:

class Migration(migrations.Migration):
    initial = True
    dependencies = [
        ('auth', '0009_alter_user_last_name_max_length'),
        ('app2', '0001_initial'),
    ]
    ...

or:

class Migration(migrations.Migration):
    initial = True
    dependencies = [
        ('app2', '0001_initial'),
        ('auth', '0009_alter_user_last_name_max_length'),
    ]
    ...

and it seems to switch back and forth with nearly every run.

Does anybody know why, or how to nail down the order? It doesn't seem to make a technical difference, but I'd like to avoid the churn/noise in our repo.

According to Simon Charette in that discussion:

It should be a simple matter of using sorted in MigrationWriter.as_string[0].

I poked around the code a bit, in hopes of first writing a failing unit test and then fixing the issue, but I'm not sure how to write the test with multiple interdependent apps since temporary_migration_module seems to support only a single app. Another concern is that the test may be flaky since the current order is indeterminate... it may take some arbitrary number of iterations to be reasonably certain the case could have been reproduced by one of them.

I'd be happy to investigate further if somebody could help me get started with some advice on writing that test.

[Simon Charette]

​Creating a Migration and assigning an unordered depedencies list and asserting they are sorted in ​the output should be an appropriate test.

[Dakota Hawkins]

Replying to Simon Charette:

​Creating a Migration and assigning an unordered depedencies list and asserting they are sorted in ​the output should be an appropriate test.

Thanks! I was looking at the test_makemigrations* tests, that looks much more promising. I'll work on it.

[Dakota Hawkins]

​PR

[Dakota Hawkins]

For what it's worth, I think a workaround may be to set ​PYTHONHASHSEED to some integer before making migrations. The migrations wouldn't be sorted, but the order would stay the same (with the same seed). Presumably the security implications of that would be minimal, as you're just generating migration files.

[Simon Charette]

After a bit more thought I agree with your conclusion Dakota, setting a fixed PYTHONHASHSEED is probably the sanest way of dealing with that given a lot more than just Migration.dependecies is likely to be ordered differently for a different seed.

Closing as wontfix because this can be worked around in the rare cases when ordering matters for your workflow. Feel free to file another ticket to allow the exclusion of the header through the makemigrations command.

[Mariusz Felisiak]

Duplicate of #34697.