The problem is detailed in #1480. We need to require Haystack > 2.3.1 to
avoid it clashing with our support for Django 1.7.

Oscar 0.7 works ok with later versions of these two packages and so we
open up the restrictions in setup.py to avoid forced downgrades for
Oscar projects.

Fixes #1477

Haystack 2.2 contains a lot of bugfixes, including a fix for Python 3.
It seems like we'd do everyone a favour by upgrading.

Security fixes mean both a new Django 1.6 and Django 1.7 version.

This is how we normally do things.

Factory Boy got a new syntax in 2.4, and was released a while ago. As
Oscar's test factories are semi-public API, it's a nice gesture to
upgrade.

* django-extra-views 0.6.5 added a pinned version of six, which causes
  issues with other dependencies that install a different version. A fix
  is already on master, but it's easier to limit the range for now.
* Haystack 2.2.0 was released and looks safe to use with Oscar. I'll
  allow that for now, but in general we should probably limit the amount
  of versions we support.

We only needed it because Django 1.4 shipped with a pretty old version
of six. Support for that has been removed, and Django 1.5 ships with six
1.6.1, which is more current than we required.

This nicely avoids an issue with django-extra-views pinning a six
version which caused the sandbox build to fail:
https://travis-ci.org/tangentlabs/django-oscar/jobs/32223978#L971

As Oscar depends directly on tables2 now, it should be returned as part
of get_core_apps, and has been removed from the requirements.txt and
INSTALLED_APPS calls.

This catches a call to unicode() and removes the unnecessary future
import for the print function.

They are both used in oscar.test, which means it's "public Oscar API".
Deployments might rely on e.g. the factories for their own test suite,
so all needed dependencies need to be installed as part of Oscar.

factory-boy 2.4 brings some nice, but breaking API changes.

The missing dependencies were discovered when working on
django-oscar-datacash, where some of the old-style factories are used,
but newfactories gets imported into that namespace.

South does not work with Django 1.7, so we shouldn't install it and
require an explicit decision by the user.

Oscar's policy is to support two versions of Django. So while there
isn't a major reason to drop support for Django 1.5, dropping support
for Django 1.6 once 1.8 is released will reduce complexity considerably.

This crude and destructive script helps create migrations for both South
and Django's native migrations framework. I'm happy to leave plenty of
room for improvement so that the King of Bash (aka @codeinthehole) can
do his thing.

This commit also enforces South 1.0. It's a backwards compatible release
which explicitly is meant to help the migration; it makes both our and
our users life's easier. Notably, it first looks for a south_migrations
directory before falling back to the migrations directory in an app.
That nicely avoids any conflicts between migration files between the two
migration frameworks.

It is now required for both Django 1.7 and Python 3 support. To keep
things simple, we now require it across the board.

This means testing against the release candidate, which should be
reasonably safe.

Debug toolbar 1.2 has some more usable panels, and less trouble with
jQuery interactions. It also is the first version to be compatible with
Django 1.7, which we'll support in the upcoming Oscar release.

django-compressor 1.4 has finally been released and supports Python 3
and comes with lots of other goodies.

sorl-thumbnail seems to be barely maintained anymore. I don't dare
switch to the beta version for Python 2. There's a few critical issues
reported on their issue tracker atm:
https://github.com/mariocesar/sorl-thumbnail/issues?labels=critical&page=1&state=open

django-nose-querycount is not Python 3 compatible and has been moved.

As requested in #1306

Be clear that we only support Python 2.

* Django version range has been bumped to a minimum of 1.4.9 because
  that's the latest security release
* Pillow has been bumped to a new max of 2.5 because Pillow 2.3.1 fixes
  a security issue
* treebeard has been bumped from it's beta to the stable release.
* Babel has been given an upper limit because that's good practice. Purl
  is developed in-house and can be left without an upper limit, and one
  can assume that six won't break backwards compatibility.

sorl-thumbnail unreleased version trips when THUMBNAIL_DEBUG isn't set.
I've submitted a pull request to fix it.

Discussion around #1200 highlighted that we must be aware of differences
between the versions of six that Django ships and the one we use.

In general, the external version of six is the best choice for Oscar,
because it allows to depend on a specific version of six. The multiple
Django versions we support each come with different versions of six,
which makes it unattractive to depend on them.

When interfacing directly with Django, it should be decided on a
case-by-case basis if it's more appropriate to use Django's supplied
version of six or the external one.

In the case of the UppercaseCharField, Django clearly documents what
needs to be done to get it to work with both Python 2 and 3 in
https://docs.djangoproject.com/en/1.6/howto/custom-model-fields/#the-subfieldbase-metaclass
Those instructions are the same for all versions of Django we support.
Hence it's been decided that it's best to switch to Django's recommended
way of declaring the metaclass, and using Django's version of six for
it.

Django-haystack==2.0.0 breaks update_index.

python-modernize (https://github.com/mitsuhiko/python-modernize) is a
useful wrapper around 2to3 which comes with sane defaults.

The fixes below were generated by running

    python-modernize --compat-unicode -w .

and then fixing all lint errors.

Let's hope both of them release a new stable version in time for Oscar
0.7.

We were using a beta release. 5.9.2 is the latest stable releases and
only has no code changes over the previously used one.

It was a dependency as Oscar used to use memcached for caching
in the sandbox. Since then, we've switched to LocMemCache and forgot to
remove it as dependency.

This requires a more recent version of Whoosh for the sandbox too.

This allows us to use the six compatibility library.

Now supports Django 1.5. Adapted CategoryForm to use the new
movenodeform_factory to build it's Meta class.

As it add some super-handy method for manipulating URLs that uses lists
of query params.  These are used for manipulating Solr URLs.

They were getting quite long. They've been split up in several
subsections. Some of them are borrowing heavily from the Django docs.

They are only really required if you are developing Oscar's CSS files -
they are not a real dependency of Oscar.

Suggested in #449.