Django's EmailField.max_length affects Postman's Migrations

It has been quite a while since Django switched to using 254 as the default EmailField.max_length. However, Postman's initial migration (0001_initial) still has max_length=75 hardcoded in it:

('email', models.EmailField(max_length=75, verbose_name='visitor', blank=True))

Also, Postman's models.py specify no max_length for the email field. Therefore, on a fresh setup, when makemigraitons is used on any other app depending on Postman (or on all apps), then Django produces a second migration for Postman to fix this conflict:

E.g. 0002_auto_20150901_2347.py

# -*- coding: utf-8 -*-
from __future__ import unicode_literals

from django.db import models, migrations


class Migration(migrations.Migration):

    dependencies = [
        ('postman', '0001_initial'),
    ]

    operations = [
        migrations.AlterField(
            model_name='message',
            name='email',
            field=models.EmailField(max_length=254, verbose_name='visitor', blank=True),
        ),
    ]

Basically, when scanning models.py, recent versions of Django sees no max_length set for the email field, and then it falls back to max_length=254 from its own default. And then, when it compares current models.py state with 0001_initial migration, it concludes with the above migration.

It's a common practice not to include third-party apps in VCS. So, this becomes a major issue when the core app/project is forced to depend on some newly produced migration which do not exist on a fresh copy of Postman installed from PyPI.

Possible fixes:

Set max_length=75 in models.py, or best, to comply with RFCs 3696 and 5321, patch 0001_initial to have:

('email', models.EmailField(max_length=254, verbose_name='visitor', blank=True))

Comments (3)