Add different configuration for different files

[Conchylicultor]

Is your feature request related to a problem? Please describe

This request is similar request to #618 (Add different configuration for different sub directories) but at the file level.

Currently, pylint apply the same config instinctively to all files. However some rules should be applied only to specific files.

For instance it is really frequent in test files to access private members (assert module._some_fn()). Currently all our tests files trigger hundreds of protected-access warnings.

Describe the solution you'd like

We would like a way to overwrite specific rules for all *_test.py files.

For instace being able to register some pattern="**/*_test.py" with custom rules associated. All files which would match the pattern would use the special pylint rules.

Note: if the pattern accept directory names (some_dir/**), it would also solve #618 while being more flexible (like: **/some_dir/**).

[AWhetter]

Although you're describing a slightly different use case, I'm closing this in favour of #618 because once that's implemented it would be the way that we would recommend solving your use case.

[Conchylicultor]

I don't think #618 solve this issue.

There are many reason where we do not want test to be located in a separate repository for example:

• Moving tests in a separate folder makes it harder to navigate between the implementation and tests.
• In tensorflow_dataset, datasets are implemented as self-contained modules containing the implementation, test, metadata,... (example). Moving tests in a separate folder would break the module abstraction.

[BrettMoan]

@AWhetter is re-opening this possible? I'd like to be able to configure pylint to ignore test files the way @Conchylicultor described.

i wouldn't think pylint should be prescriptive of "whether test files are stored in standalone tests/test, directories to support ignoring them from pylint."

I would hope that instead we would see a configurable flags for such as something like

IGNORED_FOLDER_BLACKLIST = test

IGNORED_FILES_BLACKLIST = *_test.py, test_*.py  

[Pierre-Sassoulas]

@BrettMoan this option already exists, see

--ignore=<file[,file...]>

    Files or directories to be skipped. They should be base names, not paths.

or ignore-paths introduced in pylint 2.9 if you want to use regexes.

[Conchylicultor]

I don't want to ignore the test filles. But apply different pylint rules to them.

I agree that pylint shouldn't impose were tests filles are stored.
For example at Google, tests filles are stored next to the implementation which make them much more discoverable and much more easy to navigate between test & implementation.
Google has an internal pylint version which apply different rules in test filles but it would be nice if this was natively supported by pylint as it would help open sourcing our code.

[Pierre-Sassoulas]

Google has an internal pylint version which apply different rules in test filles but it would be nice if this was natively supported by pylint as it would help open sourcing our code.

If a googler want to contribute to pylint it would be very welcome. A lot of googler already did !

From where I'm at, the per-directory configuration is something that has been planned for a long time, and it's not implemented yet because we do not have enough contributors willing to take time to implement it. The per-file configuration seems a step above that, so it's unlikely to be done in the short term unless a new contributor does it.

[ssbarnea]

I personally do not think we really need different configuration for different files but we need wildcards for disabling rules, like flake8. They call the option per-file-ignores but it works with patterns, allowing you to disable specific rules for specific files and folders.

See https://github.com/ansible-community/ansible-lint/blob/main/.flake8#L49-L62

per-file-ignores =
  src/ansiblelint/cli.py: D101 D102
  src/ansiblelint/rules/*.py: D100 D101 D102

That is kinda essential for enabling progressive improvement of codebase. You might have hundreds of thousands of problems to fix on a project and you likely want to fix them gradually.... while preventing addition of new code that is not compliant. Touching lots of files to add in-place disable does not really scale well.

[Pierre-Sassoulas]

That is kinda essential for enabling progressive improvement of codebase.

For that we have #5403