How to manage third party app migrations with custom WAGTAILIMAGES_IMAGE_MODEL - wagtail

Question

Situation
I have a custom image and rendition model, and have followed the wagtail v2.4 guide to implement them:
class AccreditedImage(AbstractImage):
"""
AccreditedImage - Customised image model with optional caption and accreditation
"""
caption = models.CharField(max_length=255, blank=True)
accreditation = models.CharField(max_length=255, blank=True, null=True)
admin_form_fields = Image.admin_form_fields + (
'caption',
'accreditation',
)
class Meta:
verbose_name = 'Accredited image'
verbose_name_plural = 'Accredited images'
def __str__(self):
credit = ' ({})'.format(self.accreditation) if (self.accreditation is not None) and (len(self.accreditation) > 0) else ''
return '{}{}'.format(self.title, credit)
class AccreditedRendition(AbstractRendition):
"""
AccreditedRendition - stores renditions for the AccreditedImage model
"""
image = models.ForeignKey(AccreditedImage, on_delete=models.CASCADE, related_name='renditions')
class Meta:
unique_together = (('image', 'filter_spec', 'focal_point_key'),)
verbose_name = 'Accredited Image Rendition'
verbose_name_plural = 'Accredited Image Renditions'
In settings I have:
WAGTAILIMAGES_IMAGE_MODEL = 'cms.AccreditedImage'
But, I have two third party plugins installed: puput and wagtail_events, each of which use a foreign key to wagtail images.
When I run `manage.py makemigrations, additional migrations are created in the puput and wagtail_events site_packages folders to handle the change in FK. The migrations look like this:
from django.db import migrations, models
import django.db.models.deletion
class Migration(migrations.Migration):
dependencies = [
('puput', '0005_blogpage_main_color'),
]
operations = [
migrations.AlterField(
model_name='blogpage',
name='header_image',
field=models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.SET_NULL, related_name='+', to='cms.AccreditedImage', verbose_name='Header image'),
),
migrations.AlterField(
model_name='entrypage',
name='header_image',
field=models.ForeignKey(blank=True, null=True, on_delete=django.db.models.deletion.SET_NULL, related_name='+', to='cms.AccreditedImage', verbose_name='Header image'),
),
]
The Problem
If I actually apply these migrations, then puput or wagtail_events releases a new version, then the migration history becomes corrupted - e.g. my autogenerated 0006* migration on puput and their new 0006* migration fork the history
The Question
Is there a way of overcoming this? Or a recommended practice for what to do?
At this point I'm in very early beta, so I could dump the entire DB and start again if the recommended strategy is to set this up from the outset to avoid the issue.
Thanks for any help, folks!

Answer 1

Answer 1 - if you have control over your third party libraries
The initial migration in the third party library should define a swappable dependency, for example:
from wagtail.images import get_image_model_string
dependencies = [
migrations.swappable_dependency(get_image_model_string()),
]
operations = [
migrations.CreateModel(
name='ThirdPartyModel',
fields=[
...
('image', models.ForeignKey(blank=True, editable=False, null=True, on_delete=django.db.models.deletion.SET_NULL, to=get_image_model_string())),
],
...
),
This is not automatically created by makemigrations. get_image_model_string needs to be used like this in every migration affecting that FK, made through the entire migration history of the library.
If you change the setting at some point in the project, you will still need to do a data migration ('Migrate an existing swappable dependency' might help), but this solves the forking problem described above if starting clean.
It has the drawback of requiring control over the third party library. I'm not holding my breath for a project like puput to go back and alter their early migration history to allow for a swappable image model (puput's initial migration hard-codes wagtailimages.Image). But I've implemented this for wagtail_events (my own project) to save other people this hassle.
Answer 2 - if you don't have control
Ugh. I've been working on this a while and all candidate solutions are all pretty horrible. I considered getting my custom image class to impersonate wagtail.images.model.Image via the db_table meta attributes, and even by creating another app which essentially duplicates wagtail images. It's all either a lot of work or super hacky.
I've chosen to take over migrations manually using the MIGRATION_MODULES setting.
For my scenario, I've taken the entire migration history of puput and copied all the files into a separate folder, root/custom_puput_migrations/. I set
MIGRATION_MODULES = {
'puput': 'custom_puput_migrations'
}
WAGTAILIMAGES_IMAGE_MODEL = 'otherapp.AccreditedImage'
Then I pull the ol' switcharoo by editing 0001_initial.py in that folder to refer to the model via the setting, rather than by hard coding:
...
from wagtail.images import get_image_model_string
class Migration(migrations.Migration):
dependencies = [
...
migrations.swappable_dependency(get_image_model_string())
]
operations = [
migrations.CreateModel(
name='BlogPage',
fields=[
...
('header_image', models.ForeignKey(related_name='+', on_delete=django.db.models.deletion.SET_NULL, verbose_name='Header image', blank=True, to=get_image_model_string(), null=True)),
],
...
Drawbacks
1) The actual table relation created is not strictly determined by the migration file, but by the setting, which could change independently. If you prefer to avoid this, you could instead simply hard-code your referred model in the custom migration.
2) This approach leaves you pretty vulnerable to developers upgrading the library version requirement without realising that they also have to manually copy across the migrations files. I suggest a check (f/ex ensuring that the number of files in the default migrations folder is the same as the number of files in the custom one) before allowing the app to boot, to ensure your development and production databases all run on the same set of migrations.