I've used vim and python for decades, but since Syntastic has been deprecated, I recently switched to ALE.

I'm coding in Python 3.11 and running vim 8.1 under Linux Mint, and have created a virtual environment using python3.11 -m venv. I installed pylint into the venv with pip, because it made the ALE/pylint import errors go away, for the other modules I installed in the venv… this doesn't really make sense to me but it's less messy than the solutions I tried from StackOverflow/StackExchange.

My project is a fairly simple command-line tool with a flat directory hierarchy. I've created a pylintrc file in that directory, which simply contains:


And I have the following options set in vim:

let g:ale_python_auto_virtualenv=1 
let g:ale_python_pylint_options = '--rcfile ./pylintrc'

I launch gvim from the command line, with my CWD set to where my pylintrc file is.

When I run pylint from the command line, it does not report this problem. This is true for both the system pylintrc (which is not the same version as in my venv—but oddly, in that case, it doesn't have trouble with the imports, either), and also when I run it from the venv Python.

I've pretty much proven that when vim/ALE runs pylint, it's not seeing my pylintrc file, because when I add garbage lines to it, it doesn't complain about them, while it does when I run it from the command line. [Edit: What I didn't notice is that it wasn't showing me pylint errors, either; rather, the errors that were appearing came from flake8. 😏] I've also created a .flake8 that sets the line length, just in case it's actually flake8 that's complaining. [Edit: Yeah, well, I stuffed that up, too—for some reason, it turns out, .flake8 needs a [flake8] header, and I didn't include that, so flake8 was ignoring that file.] The g:ale_python_pylint_options I added was an attempt to fix this problem, and I've even tried setting it to the absolute path to the pylintrc file.


  1. How can I see the command that vim/ALE actually uses to invoke pylint? How can I see the raw output?

  2. How can I tell which plug-in or app is generating the message?

I would also welcome suggestions for alternatives to ALE.

  • 2
    All that strikethrough is noise. Please remove it from your question.
    – romainl
    Dec 18, 2023 at 5:38
  • Do you still have something open in your question? How can we help you further? Otherwise may be you could accept one of the solutions using the v button next to the arrow voting buttons. It allow the question to rest :-) Dec 19, 2023 at 4:51

2 Answers 2


The :ALEInfo command produces a lot of output, including the commands that were run and the errors the respective tools reported.

Look for the lines with <<<OUTPUT STARTS>>> and <<<OUTPUT ENDS>>>, they're hard to miss. The command that was run is just above and its output is within these markers. It's a bit cumbersome to read but once you have your linters all set up, you rarely need to look.

Concerning your configuration issue, just the other day I created a .pylintrc (with leading dot but without dot works just as well) in my one of my projects containing nothing more than


And after :e in my Python source file, all the respective warnings were gone. Pylint just picked the file up. I didn't even have to touch any ALE variable.


To enable pylint for ALE I have the following line in my .vimrc:

let g:ale_linters = {
    \'python': [
    \       'pylint',
    \   ]

It seems that ALE search in the current working directory for a pylintrc file.

But since one year I don't use ALE anymore since coc.nvim that provide code completion provides also diagnostics.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.