2.0.6 appears to allow various warnings that used to be ignored

[davep]

After an upgrade to v2.0.6 (pylint 2.3.0) I'm getting various warnings of things that would otherwise have been fine. There's a small number of them, so rather than list each as a separate issue, I'll give a flavour of them here. If separate issues would be more helpful please do say so and I'll be happy to raise them.

With a large body of Django code that, with v2.0.5 of django-pylint (pylint 2.2.2), passed 10/10, I'm seeing warnings such as:

• line-too-long in many migration modules.
• Missing module docstring (missing-docstring) in many migration modules.
• Missing class docstring (missing-docstring) in many migration modules.
• Constant name "register" doesn't conform to UPPER_CASE naming style (invalid-name) in a templatetags module, complaining about a register = template.Library() line.
• Module name "0006_auto_20190204_1124" doesn't conform to snake_case naming style (invalid-name) in a migration module.

[davep]

In case it's helpful, I had a bit of time yesterday to try and work out what change caused the above to happen. After pinning everything that appeared to be related to pylint/pylint-django, I worked backwards, unpinning things. I got to a point where I could upgrade everything (pylint-django incluced, upgrading to 2.0.6) except pylint and astroid, and everything was working fine.

Only after I let pylint and astroid upgrade (to 2.3.1 from 2.2.2 for pylint, to 2.2.4 from 2.1.0 for astroid) did I start getting the sorts of errors mentioned above. So, as I'm using it now, it seems that allowing pylint to upgrade causes django-pylint to not ignore some things that would normally be ignored.

[atodorov]

I think this is the related change in pylint:

* Added ``load_configuration()`` hook for plugins

  New optional hook for plugins is added: ``load_configuration()``.
  This hook is executed after configuration is loaded to prevent
  overwriting plugin specific configuration via user-based
  configuration.

Close #2635

pylint-dev/pylint#2635

@PCManticore,
recently we've started seeing all sorts of issues reported by pylint-django which previously were not. I can share a link to Travis CI where I did take a quick look and I saw things like handler500 and errors in migrations which were explicitly handled with settings override in pylint-django.

I don't have the cycles to debug this in details but maybe you will know what is happening.