We're applying Black code style to a django project.
In all the tutorials / examples I find (such as in django cookiecutter and this blog), I keep seeing django's migrations files excluded from the linter.
But to my mind, these are still python files. Sure, django may not autogenerate them to meet the Black spec. But it's not like developers always write their code to meet Black spec... that's what linting is for!
Why would migration files be considered different to any other python files?!
NB I'm aware of the possibility of changing an already-applied migration if you've got pre-existing migrations - this requires care on first application (as does first application to the rest of the codebase, frankly) but surely isn't a reason not to do it?
EDIT - @torxed asked for an example of a django migration file
I'm not sure how helpful this'll be tbh, but a typical django migration file might look like this (in this case adding a char field to a table):
# Generated by Django 2.2.3 on 2019-10-28 09:45
from django.db import migrations, models
class Migration(migrations.Migration):
dependencies = [
('api', '0009_figures_notes_tables'),
]
operations = [
migrations.AlterField(
model_name='project',
name='processed_kmz_sha',
field=models.CharField(max_length=255),
),
]
You should rarely if ever, need to edit migration files. Because of that, it makes sense to exclude from the already agreed upon code layout of the files.
I bit the bullet and applied Black to my migrations files, progressively across half a dozen django projects.
No problems at all, everything deployed in production for months now.
So the answer is: No reason at all why not to do this, and I think migrations files should be included, so that reading them is a consistent experience with the rest of the project.