Add Django2.0 compatibility

[ticosax]

And drop django versions lower than 1.11

[rpkilby]

btw, I recently learned this syntax can be cleaned up like so:

matrix:
  include:
    - { python: 2.7, env: TOXENV=py27-django111 }
    - { python: 3.4, env: TOXENV=py34-django111 }
    - { python: 3.5, env: TOXENV=py35-django111 }
    - { python: 3.6, env: TOXENV=py36-django111 }
    ...

ref: encode/django-rest-framework/pull/5519

[ticosax]

thx @rpkilby for the suggestion.

@dfunckt what do you think ?

[dfunckt]

@ticosax @rpkilby yeah, that is readable, let's do it 👍

[ticosax]

alright, done.

[dfunckt]

@ticosax I intend to include this in rules 2.0 — is this a problem for you? Is waiting for this PR blocking you in any way?

[blueyed]

@dfunckt
The question is not clear to me: if you want to include it, then I assume you would merge it?
AFAIK @ticosax might not respond until Wednesday, and it should be OK to merge it - if that is your question?!

[dfunckt]

Hey @blueyed sorry I wasn't clear.

I'd like to include this PR in rules 2.0 because it contains breaking changes (dropping support for a bunch of Python and Django versions). But I'd also want to include a few other breaking changes in rules 2.0 (see #54) that aren't ready yet, which means this PR won't make it in a release that soon.

My question therefore is whether you're blocked on having a version of rules that has Django 2.0 support (i.e. having this PR merged), because I might then go ahead and merge this, release rules 2.0 and move the other breaking changes I wanted to include in another major version (i.e. 3.0) somewhat later. Makes sense?

[blueyed]

Oh, could have guessed it from your first comment that you do not plan to release 2.0 soonish.

I think it would make sense to have the Django 2.0 support separate, i.e. a release with fixes for Django 2.0 (extracted out of this PR), but then only later drop support for older versions?!
This might not be trivial though?!

In general it would be nice to have a release that is ready for Django 2.0, of course.

[dfunckt]

That is a good plan and I actually considered it but on quick inspection thought it wouldn't be trivial as well.

But on second look, the only non-trivial change seems to be the templatetag registration decorator, because register.simple_tag exists in Django < 2.0 as well (but with different semantics than we need?) so you possibly can't just do:

try:
  register_tag = register.simple_tag
except AttributeError:
  # Compatibility with Django < 2.0
  register_tag = register.assignment_tag

@register_tag
def test_rule ...

Edit: actually, the imports above can be the other way round and it should work fine.

Other than that, the other changes are:

1. A shim for MIDDLEWARE_CLASSES:

MIDDLEWARE = (
  # ...
)
# Compatibility with Django < 2.0
MIDDLEWARE_CLASSES = MIDDLEWARE

2. A shim for include:

try:
  # Compatibility with Django < 2.0
  from django.conf.urls import include
except ImportError:
  include = lambda x: x

If this PR was tweaked to include these changes (dropping the changes to tox.ini, etc as well) I guess it'd be fine merge it now.