Update pylint CI script to be dynamically generated

It might be best to use pylint command line options, because the config file format forces you to be redundant in a way that the command line does not, e.g. --disable=all --enable=E --enable=W.

disable=all works fine for me in the config.

I was thinking the enable list would be a whitelist, to avoid issues with future categories of errors being introduced. So, I would prefer it to be specified explicitly.

Can you have

disable=all
enable=W
disable=some-stuff

? (note the repeated disable)

I was thinking the enable list would be a whitelist, to avoid issues with future categories of errors being introduced.

I disagree. That forces that we'd have a periodic review of new warnings to adopt.

? (note the repeated disable)

No, I don't think that is possible.

I disagree. That forces that we'd have a periodic review of new warnings to adopt.

That is what I thought we wanted. I thought the point was to avoid previously compliant code from failing the CI due to introduction of new categories of errors (as happened recently in pyopencl).

That is what I thought we wanted. I thought the point was to avoid previously compliant code from failing the CI due to introduction of new categories of errors (as happened recently in pyopencl).

My read is a bit different.

• I'd like for all error-level things out of pylint to be enabled, even if new ones end up breaking builds. (What ended up breaking builds were new 'refactoring-advice' grade warnings that slipped through.)
• I'd like a single, central config for all projects.
• I'd like to be able to use that same config in my editor.

I see what you mean. There doesn't seem to be an easy way to disable specific errors in the config file if the default is disable=all; enable=E. Since only one option can be specified in the config file, it would seem like we'd have to end up using the command line to make any modifications to the default configuration file. That is not ideal, but I can live with it.

• I'd like a single, central config for all projects.

I'm not sure what you mean. Is this file supposed to serve as a base against which projects can make project-specific modifications, either through command line options or some other mechanism? (I.e, do you still think project-specific modifications are valuable?)

• I'd like to be able to use that same config in my editor.

In what scenario would this not be possible?

(I.e, do you still think project-specific modifications are valuable?)

I feel like we've had this discussion, and I've forgotten the outcome. Could you remind me: One-size-fits-all is a non-starter because...?

In what scenario would this not be possible?

If the pylint config were buried deep inside of some CI script.

I feel like we've had this discussion, and I've forgotten the outcome. Could you remind me: One-size-fits-all is a non-starter because...?

I can think of the following things that are useful:

• telling pylint to ignore whole directories (e.g. for subprojects)
• having a local list of classes with dynamically generated members to tell pylint to ignore attribute access (generated-members)
• having a local list of whitelisted C extensions (extension-pkg-whitelist)

If the pylint config were buried deep inside of some CI script.

I am thinking we could have a top-level script that downloads the right config file (if not present) and then invokes pylint with any site-specific changes.

IMO:

• Their config files are unusable, because they force redundancy. (We have to use the command line AFAICT.)
• They also don't support multiple config files as far as I can tell.

mentioned in commit ci-support@0cbf03e5

mentioned in merge request ci-support!17 (merged)

mentioned in merge request !24 (merged)

mentioned in commit 27f267a0

closed via merge request !24 (merged)