DRF FilterBackend & FilterSet

[rpkilby]

This is an attempt at #275.

Notes:

• Made FILTER_DEFAULTS a FilterSet class attribute. This allows the DRF FilterSet to modify the defaults without relying on filter_overrides. Using filter_overrides would complicate the API, as subclasses would have to copy the changes in addition to making their own.
• Made filter_overrides a meta option, providing a deprecation notice for the class attribute. This seems more correct? Behavior modifying options should exist in the class meta, not on the class itself (which should just be the declarative filters). Either way, can revert this and raise in a separate issue - I'd argue that strict and order_by_field should also be moved to meta.
• django_filters.rest_framework does not have a conditional dependency on DRF (as rest_framework.filters had on django-filter). It doesn't seem necessary, as you won't be loading the rest_framework sub-package unless DRF is installed.
• The crispy_forms conditional dependency was kept. I don't really have an opinion/preference, but it's a minimal amount of code so why not?
• Added DRF to the CI matrix.
• The FilterBackend and tests are almost entirely a carbon copy of what exists on the current DRF master branch.

Questions:

• Should the crispy_forms conditional dependency be kept?
• Should we stop providing support for python 3.2 and 3.3?
  • Most likely, it will continue working even if not officially tested
  • It's complicating the build matrix and increasing test times
  • Still, they're technically supported until 1.8 EOL's in 2018 :\

TODO:

• Add DRF relevant docs.
• Refactor.
• Wait for 453, simplify DRF requirement in testing matrix.
• Wait for 459, which contains the filter_overrides move

[carltongibson]

@rpkilby Good work! Give me a couple of days to look at this. Awesome

[kevin-brown]

Is there any reason why the formatting was changed here?

[rpkilby]

Trying to improve readability. It's definitely preference, but the compacted version is easier for me to scan than the expanded version.

[carltongibson]

@rpkilby I've updated this in #476. Very to happy to take PRs against that if you're keen. Otherwise I will clean it up and merge as is, leaving docs to come.

Thanks for the effort!

[rpkilby]

What's your timeline on merging #476 - are you trying to get that done this weekend?

[carltongibson]

@rpkilby Yes. I'd like to get it in — even if it needs a bit of follow-up work.

[rpkilby]

Sounds good - I'll try to take a look tomorrow night. If I don't have time, can always submit a PR later.

[carltongibson]

@rpkilby Awesome. If you have limited time, I'm happy to tweak this if you can work on #472 — that way we get both in!

[rpkilby]

It's more like - I'll either open my laptop or I won't. Road trip in the morning, tubing in the afternoon, but otherwise my evening should be clear 😄

[carltongibson]

@rpkilby OK. Cool. (Remember it's Open Source and doesn't own you! :-) )

[rpkilby]

Hey @carltongibson I reviewed the rebased version and decided to do some additional rebasing. I don't think I can submit a PR to the other branch because of the rebasing - do you want to reopen this PR instead?

Changes:

• removed duplicated lines (such as a duplicate fetch of filter_overrides)
• simplified the testing matrix, based on @edmorley's pull on Update Django and Python versions in testing matrix philipn/django-rest-framework-filters#101
• removed a few unnecessary commits (related to DRF 3.2, migration docs)
• FilterBackend => DjangoFilterBackend (undoing the name change)

[rpkilby]

docs added (preview here).

[carltongibson]

GitHub doesn't want to re-open this one. (Not sure why.)

Have pushed 285d7f7 as #481. I'll merge that as is.

Great work! Awesome!