Another take on compatibility

[atodorov]

@carlio here's another approach for the recent issues.

Basically my argument is that we don't need the compatibility layer, instead we need to properly annotate what kind of pylint versions we require.

I am more in favor of investing the time to use tools like PyUP.io which will automatically monitor for dependencies and start tests/pull requests or even designing our suite in Travis to execute regularly against the latest pylint/astroid so we can get a fair warning when something is about to break.

If you like this approach we can release a 2.0.4 version which requires the older version of pylint/astroid then revert the compat layer again and merge these changes on top of that with a new version (2.2 to match pylint maybe? ).

[carlio]

@atodorov

• Dependencies in build systems are a tree and pylint-django is a leaf - pylint is installed first then pylint-django afterwards, and pylint itself might be a dependency of some other part of the process, some jenkins plugin or whatever. So there will always be a range of configurations and therefore pylint-django has to be a bit willing to work with other tools.

• As said in Tidy up compat #205 : more compatability issues with more new releases means more issues for us to deal with and I'm all in favour of less issues being reported :-)

• Therefore a compatability layer is useful to avoid noise for users and for us, and to continue to be a good citizen in all the CI setups that people are using it in

One single place to put compatability fudges means it's easier to know which ones to get rid of, especially if we properly annotate which versions each "fix" refers to.

I am definitely keen to get PyPI.io or requires.io or whatever involved so that we get notified when new pylint/astroid etc releases come out as that will be helpful. I think that our initial response should be to quickly add a small workaround into the compat.py file first then work towards canonical API usage. So we have two cycles: upstream changes => first quick compatability release, then slower more relaxed pace to properly update.

So, compat layer is there to get very quick releases out to match pylint/astroid releases and that is it. Certainly I was more dependent on this workflow when I was the sole maintainer, and I think it's still worth doing it that way even now.

(( also I already released 2.0.4 as I uploaded 2.0.3 before pulling the latest master so had to delete it from Pypi, oops! ))

[atodorov]

So there will always be a range of configurations and therefore pylint-django has to be a bit willing to work with other tool

• that means we have to introduce a matrix of pylint versions (>2.0) and test with every one of them. Also automate the expansion of this matrix if possible (I've done something like this in the past)

and to ensure pylint-django is working sane with the latest and greatest:

• figure out how to test against pylint/astroid master so we get early warning when they change things.

Leaving this PR open for now as a reminder

[atodorov]

closing in favor of #210