Squash Migrations Plugin System

[jayden-arrai]

Code of Conduct

• I agree to follow Django's Code of Conduct

Feature Description

A system whereby a package could add additional code to be run while squashing migrations.

Problem

Two packages I've been involved with have a way to generate migrations which it rewrites to contain specific data. Currently squashing migrations would involve a manual process of dealing with these generated migrations, but that could be automated. I created an overriding squashmigrations in the one package, and then thought of how I would do that in the second package, and then realized there is no good way to do both. It is fine if there is only one, but there is no way for the two projects to do both of their code when squashing, as they each inherit from the original squash migrations command and the last one in the app list would win.

Request or proposal

proposal

Additional Details

I think a discussion would be needed to figure out how to create this system, since there are probably many different ways to do it. I am fine working on it, as I could test it with the two packages, but I think the how should be decided by the community, not just me.

Implementation Suggestions

In the case of the one package it deals with creating migrations for workflow. The developer makes changes locally, then runs a management command to create a migration with the data needed to be deployed to the site. Updating the site then runs the migration which makes those changes. Additional changes need the management command run again, which creates a new migration.

Squashing these migrations would be as simple as creating a new migration and copying and combining data from each of the migrations of this type into the new migration. So the code would create a second squashed migration file. Since this can happen independently of the existing squash migrations code, it can run after the current code.

The other package can create multiple migrations based on app and model, so squashing it may require multiple new squashed migrations to be created, but it as well could run after the current code.

Would running additional code after the squashed migration file is created be sufficient for everyone?

[github-actions]

Thank you jayden-arrai for sharing your idea! We have a lot of them so please be patient. You can see the current queue here.

Community instructions

For commenters, please use the emoji reactions on the issue to express support, and/or concern easily. Please use the comments to ask questions or contribute knowledge about the idea. It is unhelpful to post comments of "I'd love this" or "What's the state of this?"

Reaction Guide

• 👍 This is something I would use
• 👎 This is something that would cause problems for me or Django
• 😕 I’m indifferent to this
• 🎉 This is an easy win

[jayden-arrai]

I got claude to take a look at django and suggest some options for how this could be implemented. To allow the use of the reaction guide, I'll post them each as separate comments, so they can individually be reacted to.

[jayden-arrai]

Option 1 - New signal (post_squashmigrations)
Fire a Django signal after the squashed file is written. Each app connects a receiver in AppConfig.ready(). This is the lowest-friction pattern for N independent apps - they each hook in without knowing about each other. Downside: Django core devs have been reluctant to add more signals, and signals have weak error propagation.

[jayden-arrai]

Option 2 - Settings list registry (SQUASHMIGRATIONS_PLUGINS)
A list of dotted paths in settings.py, loaded with import_string() and called in order. This mirrors PASSWORD_HASHERS and AUTHENTICATION_BACKENDS exactly. Very explicit and grep-able, but requires each project to add an entry to settings.py.

[jayden-arrai]

Option 3 - Swappable MigrationWriter class (MIGRATION_WRITER setting)
A single dotted-path setting that replaces the writer class entirely. Clean, but only one writer at a time - this doesn't solve the two-project problem without extra delegation logic inside your custom writer.

[jayden-arrai]

Option 4 - Decorator registry (like the system checks framework)
A squash_plugins.register decorator that stores callables. Each app registers its hook in AppConfig.ready(). Mirrors django.core.checks.register() exactly - no settings change needed, and multiple apps register independently.

[jayden-arrai]

I'm not including option 5 as it wasn't very useful.
Regarding the options, claude says:
Best bets for your feature request: Options 2 and 4 are the strongest fit for Django's philosophy. Option 4 (decorator registry) has the lowest friction and the clearest precedent in the checks framework. Option 2 is better if Django devs prefer everything to be visible in settings.
I think I agree with claude. Options 1 and 3 aren't really that great.
If anyone has any other options, please list them.