id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
23982	Clarify how to properly support both Python 2 and 3 for third-party apps with migrations	Luke Plant	Carl Meyer	"The basic problem is that Python 2 produces migrations like this:
{{{
#!python
            fields=[
                ('name', models.CharField(max_length=255, verbose_name=b'First Name', blank=True)),
            ],
}}}

while Python 3 like this:

{{{
#!python
            fields=[
                ('name', models.CharField(max_length=255, verbose_name='First Name', blank=True)),
            ],
}}}
(i.e. notice the lack of `b` prefix)

If you run 'makemigrations' under Python 3, with migrations made in the first way, it creates a new migration to fix the field.


I've attached a script that shows the problem. I've tested it against master as well as Django 1.7.1 and the bug is still present. A nice unit test for this might not be possible.

There are two things to consider:

1. Fixing the generator so that it doesn't produce this problem
2. Fixing the migration code so that it doesn't consider this a problem. Otherwise, going forward, all migrations created with 1.7 and 1.7.1 will produce confusion when people use Python 3, even if we fix 1.

This bug manifests itself most obviously when running makemigrations with 3rd party apps. It looks like we were lucky when it came to the migrations bundled with Django - perhaps they were created by Python 3?
"	Cleanup/optimization	closed	Documentation	1.7	Normal	fixed			Ready for checkin	1	0	0	0	0	0