Update to django 4.2

[madtibo]

Hello,

You library was a great help to squash our 800+ migrations files on our 60+ apps \o/

We patched it so it was useable on django 4.2 and solving the issue with the Key Error.

We changed the name of the command to replace_all_migrations and forced the special not elidable operations to be written at the end of the squash files, waiting for someone to manually review them.

Hope it can help.

Bonne soirée,
Thibaut

[Krystofee]

Thx. This looks to have worked for me (im now testing it locally). But I have one question - What is the phased_migrations package and what does it do? I was unable to found any in pip or elsewhere. Should I just remove it?

[madtibo]

Coucou,
Oups, sorry, forgot about this package. It is a custom package we use to run quick schema migrations before the software upgrade and to run the longer ones (like index creation) for after the software upgrade, so we limit to the maximum the unavailability.
You can of course safely remove it.

[Krystofee]

Man, that was fast 😄 Thx.

Anyway, I took custom, more transparent approach to me: 1. backup migrations, 2. make initial, 3. set replaces on new initial migrations from backups .

That may not be as streamlined as using this package, but worked better for squashing 800+ migrations into like 20.

[flixx]

Hello @madtibo

Thanks a lot for your contribution!
Today, I found some time to do another replacement-run on our project using your branch. Things worked well and I'll hit the merge button during the next days.

There are a few things that I stumbled upon:

1. The README now says to install gg_django_replace_migrations. I am assuming that this is a left-over from your test. django_replace_migrations seems correct.
2. I saw that all RunPython operations are now added into a section into the migration that needs manual handling. It kind of makes sense, but I ended up removing this section in ~20 files by hand. In our project we use RunPython only for cases to migrate existing data. In a replacement-scenario running those data-migrations never makes sense for us because they are simply not relevant for new installations. I think it would be nice to make this behavior configurable or convert the warnings into stdout instead of modifying the migration files. However, since I won't have much time to do&test this modification myself, I am willing to accept your proposal here and simply add a few sentences about this into the README.

Thanks again for this major rewrite and for keeping this package alive!
I'll add some kudos to https://github.com/GitGuardian to the README after the merge.

Felix