My fix in 5f23648 forgot to change the receiver registration in the app
config.
Also removed an unused import, and a deprecation warning in the tests.

I was confused by what the test does, and had to ask @codeinthehole to
explain. Hopefully made it's intention a bit clearer now.

PR #1447 was by a first-time committer, so I did not want to rewrite
the commits.

* Removed accidentally committed file
* Style fixes

Closes #1447.

This commit is the squashed, but unchanged version of #1447. It adds an
__eq__ method to prices to be able to check them for equality.

This commit adds the python_2_unicode_compatible decorator to all models
that define a text representation. Furthermore, it adds a test to ensure
that we never forget to do that.

It is explained in details in the Django docs:
https://docs.djangoproject.com/en/dev/topics/python3/#str-and-unicode-methods

A custom app needs to inherit from Oscar's app config. This ensures the
correct app label, and that any startup code (receivers, etc.) is
executed.
Per the camp ground rule, the fork_app command has been slightly
refactored.

This hopefully prevents me from missing more.

I think the Oscar upgrade/forking process for forked apps will get
simpler with the new migrations. One probably will be able to just fake
an initial migration, or something like that. But for now, copying
them across as we did before should be a safe bet.

Otherwise Django 1.7 rightly complains about duplicate app labels.

South isn't supported in Django 1.7 and upwards, so we can only skip
them.

The test suite brings it's own stock record model for testing. Django
1.7 requires that we only import models from apps in INSTALLED_APPS, so
we need to use it to avoid clashes.

Fixes #1399

I'd like to move away from django_dynamic_fixture, factory_boy is so
much nicer.

The ``permissions_required`` decorator, and hence
``Application.permissions_map`` and
``Application.default_permissions``, now
handle both methods and properties on the User model. Previously, it
wasn't supported, but a docstring showed ``is_anonymous`` as an example,
which is a method.

Previously, weight based shipping methods accepted an upper charge
field. When no weight band matched the baskets weight, this was
returned. I am not aware of a single retailer who calculates shipping
charges like that. It's impossible to pick a sensible value for a
retailer, as there's no upper limit to the amount of items ordered, and
any shipping charges would have to cover costs for that.

Seems ValidationError got a rewrite for 1.6.

Based on http://stackoverflow.com/questions/12384460/allow-only-positive-decimal-numbers

Hmmm, Oscar has a PositiveInteger model field but I suspect we don't
really need it (or should refactor it to use validators).

This (possible backwards incompatible) change means subclassing and
customising shipping methods becomes much easier. Now that shipping
methods are stateless, we can instantiate at compile time and assign
them to the repository instance.

This commit also renames internal methods of the shipping repository
in as the 'prime' notion is no longer valid (as we're not injecting a
basket into each method).

It now takes the shipping charge rather than the method. This makes
sense as the shipping charge has normally been calculated before we need
the order total so there is no point in calculating it twice.

We now need to pass in the shipping charge explicitly as well as the
method. The way that the shipping discounts are persisted is also
adjusted.

As they are integration tests, not unit tests.

This was no longer being used as the checkout code had changed to load
all viable methods and then iterate over to find the appropriate one.

I presume filter returns an iterator in Python 3.

Importing things in settings is discouraged. But until now,
OSCAR_SLUG_FUNCTION could only be set as a callable, which requires
importing. It's now been updated to use the import_string function.

This completes the move away from partner wrappers to strategies. All
the methods for determining price and availability information have now
been removed from the partner classes.

The helper policy class ("DelegateToStockRecord") have been removed too
as they no longer have methods to call on the stockrecord.

We ship some apps, e.g. search, without models.py. I think that
means it is not a valid Django app for Django < 1.7. But either way,
Django 1.7 definitely allows apps without models.py, so we need to
ensure we do the right thing.

Otherwise the ModelAdmins aren't discovered.

This makes it easier to customise Oscar. You can run this command to
quickly create local versions of an app that you want to customise. The
command creates the appropriate folder, __init__.py and models.py. The
only step requiring human intervention is to modify INSTALLED_APPS to
include the new app package.

Duplicate migration numbers can happen when merging changes from
different branches. This test ensures that we address the issue right
away.

Oddly enough, the warnings were only thrown under Python 2.6. Should
investigate!

This required extending the UnicodeCSVWriter to be able to deal with
file-like objects as well. This is used to create downloadable CSV files
in memory.

TestCase.assertEquals (note the s at the end) has been deprecated.
The only failing tests remaining are CSV related, which is not
surprising.

- Comment the session manager better.
- Clean up the functional checkout tests.

Also make the availability warnings start with a lowercase char so they
can be embedded in other sentences easily.

Tests for separator and uppercase options.

Using "partner" is easily confused with passing an actual partner
instance.

As previously discussed here
https://groups.google.com/d/topic/django-oscar/Owmi3J1rwlk/discussion
I have started working on the introduction of Factoryboy library into
django-oscar, to make the generation of data for unit tests easier. At
the moment I have only refactored test/unit/address/models_tests.py, but
the plan is to refactor all the existing tests. All the tests, of
course, pass.

Squashed commit of the work done in #1192
Fixes #1192

Using timezone.now() will return naive datetimes if USE_TZ is not
enabled, which is what we want.
Resolves errors of comparing naive datetimes with aware datetimes.

It only contains importers. Also added comments about their usage,
or lack thereof.

Taken from django-extensions with some adapting to our needs.