Почему файлы миграции часто исключаются из форматирования кода?
Мы применяем стиль Black code к проекту django.
Во всех учебных пособиях / примерах, которые я нахожу (например, в django cookiecutter и в этом блоге), я постоянно вижу, что файлы миграции django исключены из линтера.
Но, на мой взгляд, это все еще файлы Python. Конечно, django может не сгенерировать их автоматически в соответствии со спецификацией Black. Но разработчики не всегда пишут свой код в соответствии со спецификацией Black... вот для чего нужен линтинг!
Почему файлы миграции считаются отличными от любых других файлов Python?!
NB Я знаю о возможности изменения уже примененной миграции, если у вас есть уже существующие миграции - это требует осторожности при первом приложении (как и первое приложение для остальной части кодовой базы, честно говоря), но, конечно, не причина не делать этого?
РЕДАКТИРОВАТЬ - @torxed запросил пример файла миграции django
Я не уверен, насколько это будет полезно, но типичный файл миграции django может выглядеть так (в данном случае добавление поля char в таблицу):
# 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),
),
]
1 ответ
Я укусил пулю и применил Black к своим файлам миграции постепенно в полдюжине проектов django.
Вообще никаких проблем, все развернуто в производстве уже несколько месяцев.
Итак, ответ таков: нет никаких причин, почему бы этого не сделать, и я думаю, что файлы миграции должны быть включены, чтобы их чтение было согласованным с остальной частью проекта.
Вам будет редко, если вообще когда-либо, нужно редактировать файлы миграции. В связи с этим имеет смысл исключить файлы из уже согласованного макета кода.