Migration writer includes kwargs for operations even if they don't occur in the deconstruct output

[Markus Holtermann]

In 21e21c7bc2b8bf7ae127e2aa75048a60d05a6e0f (#23844) we introduced a way to deterministicly deconstruct migration operations that don't rely on the argument ordering. However, the migration writer still includes all arguments of an operations, since it inspects the operation's __init__() function (see ​django/db/migrations/writer.py#L51-L52).

This behavior makes migrations generated under 1.8 practically unusable on 1.7, even if they don't use managers in migrations. Due to this I classify this issue as a release blocker.

See also #23892 for a discussion about the forwards / backwards compatibility of migrations.

[Markus Holtermann]

PR: ​https://github.com/django/django/pull/3853

[Carl Meyer]

As I said on #23892, I don't think we should attempt to make migrations forwards-compatible, and I actually see some advantage to having them fail fast if you try rather than "maybe work depending which features you use." So I don't believe this is high priority or should be a release blocker.

However, I do think this is worth fixing, not for forward-compatibility but just for the sake of cleaner migration files. And if we want it to "fail fast" when you use newer migrations on older Django, we should do that in a more explicit way anyway. So I'm +0 on merging this change.

[Markus Holtermann]

It's not about forwards compatibility, at least I didn't consider and think about it. The output is just not the way as it was intended by the change.

[Carl Meyer <carl@…>]

In 862ea825b5073588efafd5b7eed349ad098b5fe1:

Fixed #24093 -- Prevented MigrationWriter to write operation kwargs that are not explicitly deconstructed