Open ddaanet opened 7 years ago
One more for displaying stderr output as a notification regardless of pylint exit status:
My project has some legacy code that uses database introspection at init time. To be able to run pylint, I need a ssh tunnel to the development virtual machine. If the ssh tunnel is broken (which tends to happen on sleep-wakeup), pylint fails with a stderr message telling the connection to the database failed.
Right now, I need to display the development pane, and unfold the error to see that I need to restart the tunnel. If stderr was displayed as a notification, I could diagnose the problem immediately.
Similar issue: pylint_django v0.8.0 is the last to support Python 2. When it loads under Python 2, it spits out the following on stderr:
/home/nighty/.virtualenvs/capman/local/lib/python2.7/site-packages/pylint_django/__init__.py:11: DeprecationWarning: Version 0.8.0 is the last to support Python 2. Please migrate to Python 3!
"Please migrate to Python 3!", DeprecationWarning)
My current workaround is manually patching pylint_django in my venv, but I would also prefer my linter plugin to be a bit less brittle. ;)
linter-pylint
throws an exception when any unexpected output is found on stderr.If that happens, the user gets a red burning notification, a traceback in the console, and no lint results even if the command was run successfully. That turns annoying but minor issues in crash blocking issues.
Two cases where unexpected stderr output occured:
185 pylint 1.6.4 warns about deprecated configuration settings on stderr. Those warnings are no longer displayed in pylint 1.7.1.
212 faulty shell configuration causes the virtualenv wrapper script for pylint (which is a shell script) to print some errors.
In both cases, the stderr output indicates some annoying problem in pylint or other system components, but does not prevent pylint from running.
Unexpected stderr output should be displayed to the user in some way. I can see two options:
Stdout should be processed and returned to
linter
for display even if unexpected stderr output occurred.One could also check pylint exit status. https://pylint.readthedocs.io/en/latest/user_guide/run.html#exit-codes (status 1 is also used if pylint crashed, or the file did not exist, etc.)
But, why bother? If there's linter output we can parse, it should be parsed. If there's unexpected stderr output, it should be displayed.