[Django] #25906: `squashmigrations` generates migrations that don't work with Python 3
Django
----------------------------+--------------------
Reporter: patrys | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.9
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Easy pickings: 0 | UI/UX: 0
----------------------------+--------------------
When I run `squashmigrations` I get something similar to the following:
{{{
class Migration(migrations.Migration):
replaces = [(b'registration', '0001_initial'), (b'registration',
'0002_auto_20151203_1158')]
...
}}}
Notice how app names are passed as `bytes` instances.
Now in Python 3 a `bytes` objects is never equal to its Unicode (`str`)
representation. This inequality makes Django consider the squashed
migration conflicting with the migrations it replaces.
--
Ticket URL: <https://code.djangoproject.com/ticket/25906>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: patrys | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.9
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
Comment:
It's another case of #24949 (we could coerce the `app_name` bytestring),
but an alternative is to add `from __future__ import unicode_literals` to
the `apps.py` in the project template as we do for other files. I think
the latter solution could be backported to 1.9. Should we create a
separate ticket for that and close this as a duplicate of #24949?
--
Ticket URL: <https://code.djangoproject.com/ticket/25906#comment:1>
Django
Reporter: patrys | Owner: nobody
Type: Bug | Status: new
Component: Migrations | Version: 1.9
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Comment (by patrys):
I don't think changing the project template will help anyone who faces
this problem as it means they already have a settings file. IMO Django
should tell users to fix their settings and refuse to create broken
migrations.
--
Ticket URL: <https://code.djangoproject.com/ticket/25906#comment:2>
Django
Reporter: patrys | Owner: nobody
Type: Bug | Status: closed
Component: Migrations | Version: 1.9
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
Changes (by timgraham):
* status: new => closed
* resolution: => duplicate
Comment:
We have the same problem (bytes/unicode discrepancy) in other places since
Django 1.7 and another solution has been proposed in #24949 so I'll add a
note about this there and mark this as a duplicate. We don't know whether
or not a user intends migrations to work on both Python 2 and 3, so
starting to throw errors when it's not really an error could be annoying.
If you disagree with the solution proposed in #24949, could you leave a
comment there?
I created #25909 for the `unicode_literals` proposal.
Thanks for raising the issue!
--
Ticket URL: <https://code.djangoproject.com/ticket/25906#comment:3>