Why are migrations files often excluded from code formatting?

Question

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),
        ),
    ]

Could you give an example of which such files are "different from all others"? (Small examples are welcome) — Torxed, May 31 '20 at 16:21
Mainly because I was curious as I don't fully understand what you mean by "these pythons different to all the other pythons", so I'd hope a few more details might clear up the linguistic barrier in case more experienced django people came along :) But I'm starting to sense that this is one of those edge cases where, if you haven't had this very exact issue you won't have a clue what it's all about anyway heh. — Torxed, May 31 '20 at 20:20
"all the tutorials / examples I find" it would be helpful to link to at least some of them. — MisterMiyagi, May 31 '20 at 20:51
Sorry @torxed, it's just a british sense of humour creeping in, it was inconsiderate of me not to realise that wouldn't be easy for the entire community. Editing now to make the question clearer! — thclark, Jun 01 '20 at 05:00

score 8 · Accepted Answer · answered Sep 14 '20 at 14:42

8

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.

answered Sep 14 '20 at 14:42

thclark

4,784
3
39
65

But how do you run the formatter on new migration files? You usually don't open and save migration files in your editor, so any time your commit has a migration you have to run `git commit` twice so that they get formatted by [pre-commit](https://pre-commit.com/)? That seems tedious. – Boris Verkhovskiy Jan 30 '22 at 04:02
It's just pressing the up arrow and then enter, @Boris. And it's pretty rare that you make migrations in a stable project, so honestly really can't say I've ever noticed. – thclark Jan 30 '22 at 08:25

score 0 · Answer 2 · answered Jul 10 '20 at 18:18

0

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.

answered Jul 10 '20 at 18:18

Arthur Choate

513
5
20

1

Hmm, you do read them from time to time though, and usually at times when the worst mess has happens and so it helps in reading them if they're the same as everything else. So this doesn't track with me to be honest. – thclark Jul 12 '20 at 11:47
That is still the answer to the question however. – Arthur Choate Jul 12 '20 at 13:19
I have to disagree, Arthur - it's a non-sequitur that you don't need to apply a style guide to code because you don't edit it much (or maybe ever). That statement would apply to all boilerplate code (as well as well-tested code that just sits there year after year unchanged). – thclark Jul 12 '20 at 15:11
It does not apply to all boilerplate code because only migrations files share the characteristic of being rarely edited AND formatted upon an already agreed upon standard. It is also not a non sequitur. The evidence is in relation to the conclusion. – Arthur Choate Jul 12 '20 at 16:41
Caused me to dig deeper. The docs note an ["agreed upon object layout and declarative style"](https://docs.djangoproject.com/en/3.0/topics/migrations/#migration-files) but there's no specified or agreed upon code style either in the docs or anywhere I can find on the django issues tracker... – thclark Jul 12 '20 at 20:32

Why are migrations files often excluded from code formatting?

2 Answers2