Question 136213 in Visual Studio Code Question posted in
View the official documentation.

Visual Studio Code – Disable errors in .pylintrc doesn't work in VS Code

I met strange behavior of pylint in VS Code. ‘.pylintrc’ doesn’t recognize after recreating.
My steps:

  1. Install pylint in VS Code

  2. Set pylint as linter using ‘Python: Select linter’ command

  3. Add ‘.pylint’ with disabling some of warnings:

    [MESSAGES CONTROL] disable=missing-function-docstring,
    missing-final-newline,
    missing-class-docstring,
    missing-module-docstring,
    invalid-name,
    too-few-public-methods

And it works fine! But then I tried to set pylint configuration in ‘pyproject.toml’:

[tool.pylint.messages_control]

disable = ["missing-function-docstring",
        "missing-final-newline",
        "missing-class-docstring",
        "missing-module-docstring",
        "invalid-name",
        "too-few-public-methods"
]

After that exluded warnings shows again.
enter image description here

Ok, I deleted ‘pyproject.toml’ and return ‘.pylintrc’ – no effect. I tried to select linter again, reopen VS Code, reinstall pylint, but nothing helps.

Version: 1.70.0 (user setup)
Commit: da76f93349a72022ca4670c1b84860304616aaa2
Date: 2022-08-04T04:38:16.462Z
Electron: 18.3.5
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: 10.0.139.17-electron.0
OS: Windows_NT x64 10.0.19044

pylint version 2.15.0

Tags:

2

Answers


  1. 0

    Two things:

    1. Configuring pylint via pyproject.toml is indeed a hassle, because this specific file only gets respected if pylint is run from precisely that directory. Many IDEs however (Spyder at least, but it seems PyCharm is similar) apparently always run pylint from the respective subdirectory, i.e. from the folder that directly contains the file undergoing linting. Thus, your pyproject.toml isn’t respected in these cases. (If you find this behavior weird, you’re not the only one, but that’s how pylint currently does it.) So this is the underlying reason for the errors in your screenshot. On the other hand, any .pylintrc in the project does indeed get respected even when pylint is run from inside a subdirectory. So for now I would indeed recommend configuring pylint by a .pylintrc in your project and not by pyproject.toml. (I think there is some option whereby one can make .pylintrc just point to the pyproject.toml, which would then hold all the concrete configuration and would be respected even from subdirectories – this would then be the best solution for the time being.)

    2. To resolve your issue that remains with .pylintrc: Tell pylint to show you the path of the configuration file which it uses when it’s called. For this, use the command line: cd into the directory in question and run pylint in verbose mode: pylint --verbose. This shows you what config file is being used. (For instance, you might have a long-forgotten pylintrc or .pylintrc sitting around somewhere in your home directory that gets loaded.)

    By the way, this trick – using verbose mode to see what configuration file is actually being used – is useful with many tools.

    Login or Signup to reply.
  2. 0

    Maybe a bit too late for OP, but probably interesting for others:

    I struggeled with the same problem, but using the locally installed pylint via Pipfile in a virtual environment (venv). It seems the pylint command line parameter rcfile solves this. In settings.json write

    {
  //...,
  "python.linting.pylintEnabled": true,
  "python.linting.pylintArgs": [
    "--rcfile=api/pyproject.toml",
  ],
  //...,
}

    if you had the following file structure

    workspace-dir/
 | - .vscode/
 |    '- settings.json
 | - api/
 |    |- src/
 |    |  |- ...
 |    |- pyproject.toml
 |    '- ...
 '...

    where the Python project, including pyproject.toml, is inside the subdirectory api

    Note: this works likewise with a .pylintrc file by writing --rcfile=api/.pylintrc to the settings.json instead

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search