Native migrations created with Python 2 differ from ones created with
Python 3. More importantly, they failed when used in Python 3, but not
vice versa. This is caused by field names being marked as byte strings
when using Python 2.
This rewrites the native migrations, which probably isn't a bad thing
either, because they were created with a pre-RC2 version of Django, and
Django 1.7 has since seen a few more migration-related fixes.
It's likely Django now does the correct thing and generates Python 2 and
3 compatible migrations under both versions of Python.
To create test databases, the Django test runner calls the 'migrate'
management command, and I think the current Nose test runner calls
'syncdb', which under Django 1.7 is aliased to 'migrate'.
This command inspects the migration graph to figure out the migrations
to run. So it inspects the migrations that ship with Oscar. Some of them
depend on the partner or customer migrations. The test suite swaps out
those apps. Until now, the command then couldn't find the initial
migrations and would fail with a dependency error.
As far as I can tell, there's no good way to just call what used to be
"syncdb" and ignore migrations completely. So for now, we will have to
create migrations for the test apps that replace Oscar.
Call signal receivers from models.py (not __init__.py)
This reverts fa1f8403 which moved them from models.py to __init__.py.
As reported by @mvantellingen, importing receivers from __init__.py
breaks the way models are normally overridden as it causes the core
models.py to get imported before the custom one.
We need to move back to the old system and will need to advise that the
debug toolbar needs to be set-up explicitly to avoid circular import
issues with models.
Fixes #1159
Original issue #1125