msherry / flycheck-pycheckers

Multiple syntax checker for Python in Emacs, using Flycheck

flycheck-pycheckers

Multiple syntax checker for Python in Emacs, using Flycheck

Copyright Marc Sherry [email protected]

This package provides a way to run multiple syntax checkers on Python code, in parallel. The list of supported checkers includes:

• pylint
• flake8
• pep8
• pyflakes
• mypy (for both Python 2 and 3)
• bandit

This is an alternative way of running multiple Python syntax checkers in Flycheck that doesn't depend on Flycheck's chaining mechanism.

Flycheck is opinionated about what checkers should be run, and chaining is difficult to get right (e.g. see flycheck/flycheck#836, flycheck/flycheck#1300). This package assumes that the user knows what they want, and can configure their checkers accordingly -- if they want to run both flake8 and pylint, that's fine.

This also allows us to run multiple syntax checkers in parallel, rather than sequentially.

Quick start

Installation via MELPA is easiest:

M-x package-install <RET> flycheck-pycheckers <RET>

Then, in your init.el:

(global-flycheck-mode 1)
(with-eval-after-load 'flycheck
  (add-hook 'flycheck-mode-hook #'flycheck-pycheckers-setup))

Start editing a Python file!

For more details on using Flycheck in general, please see http://www.flycheck.org/en/latest/user/quickstart.html. The error list (viewable with flycheck-list-errors, bound to C-c ! l by default) shows a unified view of all errors found by all checkers, with line and column information where available.

flycheck-pycheckers can run over any Python file right away, without needing to set up virtual environments or driver scripts. You will simply need to ensure that the checkers you want to run (pep8, mypy, flake8, etc.) are installed somewhere on your PATH where Emacs can find them.

Alternatives:

• Other Flycheck-based checkers -- Some are officially part of the Flycheck package, and some (like this one) are external plugins.
• Flymake -- Flymake is an older syntax-checking minor mode for Emacs, and is generally less supported and featureful than Flycheck.

Configuration options

You can use this package without needing to get into these details at first -- they are intended for power users and those needing more customization.

There are a number of options that can be customized via customize-variable, which all start with flycheck-pycheckers-. These include:

• flycheck-pycheckers-args - general arguments to pass to pycheckers.py.
• flycheck-pycheckers-checkers - the set of checkers to run (pylint, pep8, mypy, etc.). Can be set in .pycheckers files with the variable checkers as a comma-separated list of checker names.
• flycheck-pycheckers-ignore-codes - a set of error codes to universally ignore. These can be set more granularly (e.g. per-project) using the .pycheckers file described below.
• flycheck-pycheckers-max-line-length - the default maximum line length. Can be overridden via .pycheckers file.
• flycheck-pycheckers-multi-thread - whether to run each checker simultaneously in its own thread, for performance.
• flycheck-pycheckers-venv-root - a directory containing Python virtual environments, so that imports may be found.

Additionally, a .pycheckers file may be created in a directory to control options for every file under this directory. These files may be logically combined, so a project may have one set of options that may be selectively overridden in a specific subdirectory.

Example .pycheckers file:

[DEFAULT]
max_line_length = 120
mypy_config_file = ci/mypy.ini

Variables that can be set in the configuration file include the following. Note that these are implemented as modifying the values received by argparse in the pycheckers.py script, so running bin/pycheckers.py --help is a good way to find other options that may be specified.

• <checker>_command - a customized command for running a given checker. For example, if you work at a company that provides its own driver script/daemon for running mypy, give the path to the daemon here as mypy_command = /usr/local/bin/mypy-daemon.
• max-line-length - the maximum allowable line-length. This is a good option to place in a project-specific directory if you have a personal line length preference set by default via flycheck-pycheckers-max-line-length, but also work on projects that follow different standards.
• checkers - a comma-separated list of checkers to be run for files under this directory. If, for instance, pep8 should not be run on a directory of auto-generated code, this option can accomplish that.
• ignore_codes - a comma-separated list of error/warning codes to ignore for files under this directory. Replaces the current set of codes completely.
• merge_configs - whether to keep traversing upwards when parsing .pycheckers files, or stop at this one.
• extra_ignore_codes - a comma-separated list of error/warning codes to add to the current set of ignored errors. This can be used to make certain directories conform to different levels of syntax enforcement. For example, a directory containing auto-generated code may omit various warnings about indentation or code style.
• pylint_rcfile - the location of a project-specific configuration file for pylint
• mypy_config_file - the location of a project-specific configuration file for mypy
• flake8_config_file - the location of a project-specific configuration file for flake8

---

Converted from flycheck-pycheckers.el by el2markdown.

flycheck-pycheckers's Issues

flake8 config is ignored

I have a .flake8 and setup.cfg with ignore = C812 (trailing commas). The warning does not appear when running flake8 manually, but I still get the flake8 message about cli.py from flycheck-pycheckers. It does work if I put extra_ignore_codes = C812, but that seems like it shouldn't be necessary.

Here's a demo repo https://github.com/apnewberry/demo

flycheck-pycheckers 0.11.5
flake8 3.5.0 (flake8_commas: 2.0.0, mccabe: 0.6.1, pycodestyle: 2.3.1, pyflakes: 1.6.0) CPython 3.6.6 on Linux
emacs 26.1
python 3.6
ubuntu 18.04

Related issue: #12

pep8 renamed to pycodestyle

During a fresh install of Ubuntu, I noticed that the pep8 command is now distributed as pycodestyle. It would be nice to support this in the bin/pycheckers.py scripts.

This package used to be called pep8 but was renamed to pycodestyle to reduce confusion. Further discussion can be found in the issue where Guido requested this change, or in the lightning talk at PyCon 2016 by @IanLee1521: slides video.

Quote from https://pypi.org/project/pycodestyle/

I can make the change if you want but what would be the best approach:

• Consider it a new linter class based on pep8.
• Adapt pep8 class to detect which binary is installed in the system.

"failure of some kind" error message could be more helpful

Hi. I just tried installing this package - and thanks for writing / releasing / maintaining it! I get errors when I visit a Python file:

mypy:Checker indicated failure of some kind
mypy:usage: mypy [-h] [-v] [-V] [more options; see below]
mypy:            [-m MODULE] [-p PACKAGE] [-c PROGRAM_TEXT] [files ...]
mypy:mypy: error: Mypy no longer supports checking Python 2 code. Consider pinning to mypy<0.980 if you need to check Python 2 code.

flake8:Checker indicated failure of some kind

But there is no indication of what the errors are so I don't know what to do next, other than look at the flycheck-pycheckers elisp and see if I can find and output the error message. But it feels like I shouldn't need to be doing that and that I am somehow doing something wrong...

Thanks for any help.

mypy.ini per-file options not respected

Flycheck actually runs its checkers over a file named flycheck_<real_file_name>.py, which causes the file-specific sections in mypy.ini files not to match anything. E.g., for the config file

[mypy]
platform = darwin
follow_imports = skip
ignore_missing_imports = True
warn_redundant_casts = True
warn_no_return = True
show_traceback = True
strict_optional = True

[mypy-path.to.file.heres_a_file]
strict_optional = False

the options in the [mypy] section will be correctly applied when checking file heres_a_file.py, but the specific options will not, since flycheck will see it as flycheck_heres_a_file.py.

Pycheckers not returning casing errors for pylint

Hi there! I'm getting different results running pylint via pycheckers and pylint via flycheck. Here's where I am so far:

flycheck/flycheck#1544

Thanks!

This is a bug? Or my wrong?

pycheckers.py overrides values from flake8 config by passing explicit --ignore=

$ cat foo.py
#################################################################################
from __future__ import absolute_import, division, print_function
class FooException(Exception): pass
import os
print('{!r}'.format(os.environ.get('PWD')))
$ cat tox.ini  # one of the places flake8 looks for its config
…
[flake8]  # --------------------------------------------------------------
ignore = E302,E305,E402,E501,E701
# E302 - expected 2 blank lines, found ...
# E305 - expected 2 blank lines after end of function or class
# E402 - module level import not at top of file
# E501 - line too long (... > ... characters)
# E701 - multiple statements on one line (colon)
…
$ flake8 foo.py
$ ~/.emacs.d/elpa/flycheck-pycheckers-20171207.1754/bin/pycheckers.py --checkers flake8 foo.py
WARNING E501:flake8: line too long (81 > 80 characters) at foo.py line 1,81.
WARNING E302:flake8: expected 2 blank lines, found 0 at foo.py line 3,1.
WARNING E701:flake8: multiple statements on one line (colon) at foo.py line 3,30.
WARNING E305:flake8: expected 2 blank lines after class or function definition, found 0 at foo.py line 4,1.
WARNING E402:flake8: module level import not at top of file at foo.py line 4,1.

This looks like it's happening because flake8 is given an explicit --ignore= parameter, which overrides config file values:

$ ipdb3 ~/.emacs.d/elpa/flycheck-pycheckers-20171207.1754/bin/pycheckers.py --checkers flake8 --multi-thread=false foo.py
> /…/.emacs.d/elpa/flycheck-pycheckers-20171207.1754/bin/pycheckers.py(12)<module>()
     11 Later improvements by Marc Sherry <[email protected]>
---> 12 """
     13

ipdb> b 198
Breakpoint 1 at /…/.emacs.d/elpa/flycheck-pycheckers-20171207.1754/bin/pycheckers.py:198
ipdb> c
> /…/.emacs.d/elpa/flycheck-pycheckers-20171207.1754/bin/pycheckers.py(198)run()
    197             args.append(filename)
1-> 198             process = Popen(
    199                 args, stdout=PIPE, stderr=PIPE, universal_newlines=True,
ipdb> print("'{}'".format("' '".join(args)))
'/usr/bin/env' 'flake8' '--ignore=' '--max-line-length' '80' 'foo.py'
ipdb> q
$ '/usr/bin/env' 'flake8' '--ignore=' '--max-line-length' '80' 'foo.py'
foo.py:1:81: E501 line too long (81 > 80 characters)
foo.py:3:1: E302 expected 2 blank lines, found 0
foo.py:3:30: E701 multiple statements on one line (colon)
foo.py:4:1: E305 expected 2 blank lines after class or function definition, found 0
foo.py:4:1: E402 module level import not at top of file

If one wants to be able customize ignored errors from Emacs, one likely needs a way to differentiate between "don't pass any --ignore argument to the underlying linter" and "pass --ignore= to the underlying linter, because I don't want to ignore anything". I toyed around with the idea of trying to omit the --ignore parameter to pycheckers.py where flycheck-pycheckers-ignore-codes was nil (and optionally setting its default to nil), but I'm not sure if this is the right approach. That would likely require changes to both flycheck-pycheckers.el and pycheckers.py.

Question: what is the evaluation context of .pycheckers ?

I have specified a relative pathname for my mypy config file in .pycheckers. I would prefer not to use an absolute path name, because then I wouldn't be able to move it between machines or share it.

But this seems to work unpredictably, because the relative pathname seems to be interpreted relative to various different working directories. I believe that the .pycheckers file should be loaded in the context of its own location, rather than in the context of the current working directory. Is this possible?

If this is not possible, is there something I can put in this file as a way of referring to "here" (the file's location) to turn my relative pathname into an absolute one?

`flycheck-pycheckers-setup` is void

The typical use-package code doesn't work:

(use-package flycheck-pycheckers
  :init
  (with-eval-after-load 'flycheck
    (add-hook 'flycheck-mode-hook #'flycheck-pycheckers-setup)))

because the package autoload isn't being generated properly:

diff --git a/flycheck-pycheckers.el b/flycheck-pycheckers.el
index 45d08f3..a38621e 100644
--- a/flycheck-pycheckers.el
+++ b/flycheck-pycheckers.el
@@ -283,7 +283,7 @@ per-directory."
   (interactive)
   (setq flycheck-checkers (remove 'python-pycheckers flycheck-checkers)))
 
-;;; ###autoload
+;;;###autoload
 (defun flycheck-pycheckers-setup ()
   "Convenience function to setup the pycheckers flycheck checker."
   (interactive)

If you add the source directly to your load path, the issue doesn't appear.

Pylint crashes not raised

When pylint crashes, e.g with the following error:

Traceback (most recent call last):
  File "/Users/msherry/.virtualenvs/client/bin/pylint", line 11, in <module>
    sys.exit(run_pylint())
  File "/Users/msherry/.virtualenvs/client/lib/python2.7/site-packages/pylint/__init__.py", line 23, in run_pylint
    Run(sys.argv[1:])
  File "/Users/msherry/.virtualenvs/client/lib/python2.7/site-packages/pylint/lint.py", line 1273, in __init__
    'init-hook')))
  File "/Users/msherry/.virtualenvs/client/lib/python2.7/site-packages/pylint/lint.py", line 1374, in cb_init_hook
    exec(value) # pylint: disable=exec-used
  File "<string>", line 4, in <module>
  File "/Users/msherry/.virtualenvs/client/bin/../lib/python2.7/posixpath.py", line 122, in dirname
    i = p.rfind('/') + 1
AttributeError: 'NoneType' object has no attribute 'rfind'

it is not detected correctly. We should do a better job of differentiating between exit statuses due to lint problems vs. checker crashes.

flycheck-pycheckers - what is the purpose of this package?

hi, i am trying to understand why we have package like "flycheck-pycheckers"?

currerntly in my python-mode i am using flycheck and i have below checkers: python-flake8, python-pylint, python-pycompile. I can easily add more if i want, but i dont need it.

so when i will run M-x flycheck-list-errors then i have table with errors which are provided by different checkers. So i can see that errors are validating via multiple engines.

so in this case - is this package still needed & useful?

Supporting additional checkers?

I'm a big fan of flycheck-pycheckers. I ran across some additional checkers (most in prospector) that seem useful. I wonder how hard it'd be to include any of these in pycheckers?

• bandit - 1119 stars, original repo + 15 stars
  Bandit is a tool designed to find common security issues in Python code. To do this Bandit processes each file, builds an AST from it, and runs appropriate plugins against the AST nodes. Once Bandit has finished scanning all the files it generates a report.

• pydocstyle - 424 stars
  pydocstyle is a simple tool to warn about violations of the PEP257 Docstring Conventions. It produces messages for any divergence from the style guide.

• vulture - 219 stars
  Vulture finds unused classes, functions and variables in your code. This could be useful if your project is an application rather than a library, however, if you do a lot of dynamic access or metaprogramming, Vulture will likely warn about unused code that is in fact used.

• mccabe - 158 stars
  McCabe or cyclomatic complexity is a measurement of how many paths there are in a given function or method. It measures how complicated your functions are, and warns if they reach a certain threshold. Methods that are too complex are prone to logic errors, and should be refactored to a series of smaller methods.

• dodgy - 52 stars (possibly unmaintained)
  Dodgy is a very simple tool designed to find ‘dodgy’ things which should not be in a public project, such as secret keys, passwords, AWS tokens or source control diffs.

• pyroma - 43 stars
  Pyroma is a tool to check your setup.py to ensure it is following best practices of the Python packaging ecosystem. It will warn you if you are missing any package metadata which would improve the quality of your package. This is recommended if you intend to publish your code on PyPI.

Add pydocstyle checks

Start pycheckers.py or checkers from cvs root or from emacs cwd

Currently pycheckers.py is invoked with the checked file dirname as its working directory, so checkers are also started with their files directories as cwd.

Typically if I have tests/test_app.py I would manually run pylint tests/test_app.py but flycheck-pycheckers would run the equivalent of (cd tests; pylint tests/test_app.py).

This is probably bad, first because that's not how users start their linters, so they may see differences between flycheck-pycheckers and their manually started linters.

Typical differences is if their checked files are importing files available at the root the the repository, running pylint tests/test_app.py would work, but cd tests; pylint test_app.py would report an import error.

I think pycheckers should be ran relatively to the emacs cwd (where emacs was initially started) but in some cases and some habits it may be wrong, and using the cvs root may be better, so I'm still unsure on what's best here, maybe this need feedback from users.

Default line width does not match checker's defaults

pycheckers uses the default max-line-width of 80 - which is different to flake8 default (79), PEP8 recommendation (79) and pylint default (also 79).

This discrepancy means that if I use pycheckers on a project that does not customize this value in .pycheckers file, and there are 80 characters in some lines, then

• running any checker (e.g. flake8) from command-line correctly reports line-too-long errors
• pycheckers does not report any errors

Of course I can circumvent this by setting the line width limit to 79 in the .pycheckers configuration, but I suppose a wrapper around other checkers should not introduce any code style bias by using different defaults than the checkers it wraps.

Python 3?

I was recently reading that the next minor update to macOS (12.3) will finally remove python 2.x (not to mention that 2.x has been EOL for a while now) which got me wondering if porting pycheckers to 3.x would be a big pain.

If someone wants to run a 2to3 pass and set up a test branch or something, I'd be happy to help test it out (at least the mypy3 and pylint checkers). Also happy to set up said branch myself otherwise. Anyone else interested or has anyone tried this already?

pylint does not run if no .pylintrc file is present

We tried to be lazy and use flycheck's machinery to find a .pylintrc file, which works great if it's there. If it's not, then pylint just crashes. We should find it ourself if we can, and if not, don't pass the argument to pylint.

Mypy reveal_type() gets suppressed

I just came back to a project after a while and noticed that I'm no longer able to do use Mypy's reveal_type() with pycheckers. Mypy is emitting an error level of 'note:' in this case which seems to get filtered out by fixup_data() in pycheckers' mypy checker. Perhaps mypy used to emit errors and not notes for reveal_type()?..
I'm able to work around it for now by hacking fixup_data() to map that particular case back to an error, but perhaps you'd want to fix this in a cleaner way? (I'd be happy to throw my hack up as a PR if not; just let me know)
-Eric

"Can't find source file" with tramp-mode

Hi,

everything seems to work nicely when working with local files but when I enable flycheck-mode on a file opened through tramp-mode on aws I'm getting this:

Suspicious state from syntax checker python-pycheckers: Flycheck checker python-pycheckers returned 1, but its output contained no errors: Traceback (most recent call last):
  File "/home/jussi/.emacs.d/straight/build/flycheck-pycheckers/bin/pycheckers.py", line 1274, in <module>
    main()
  File "/home/jussi/.emacs.d/straight/build/flycheck-pycheckers/bin/pycheckers.py", line 1227, in main
    raise RuntimeError("Can't find source file %s" % source_file_path)
RuntimeError: Can't find source file /ssh:some_server:/path_to_file/flycheck_file.py

Try installing a more recent version of python-pycheckers, and please open a bug report if the issue persists in the latest release.  Thanks!

This is what I have in config.el

(use-package flycheck-pycheckers
  :after flycheck
  :ensure t
  :init
  (with-eval-after-load 'flycheck
    (add-hook 'flycheck-mode-hook #'flycheck-pycheckers-setup)
    )
  (setq flycheck-pycheckers-checkers
    '(
      mypy3
      pyflakes
      )
    )
  )

I'm not sure if flycheck-pycheckers is the source of the problem or something else (...the whole config.el is a bit involved...), but is this supposed to work also on files opened over tramp-mode?

Thanks!

mypy --quick-and-dirty no longer available

I just noticed that mypy has officially killed off the --quick-and-dirty option that flycheck-pycheckers uses:
python/mypy@b922266

Are there any plans to add support for mypy's daemon mode (the recommended replacement)? I'd be happy to help test or take a whirl at wiring it up if it'd be helpful. The checker still works without quick-and-dirty mode but iteration is noticably slower.

bin/pycheckers.py script fails if no python is available

On Ubuntu 20.04 a "python" executable is not available. Instead, "python3" is, by default.
Therefore, bin/pycheckers.py, which uses the preamble:

#!/usr/bin/env python

fails on new Ubuntu installations.
Manually amending it works.
People may be reluctant to mess with system-wide Python installations and create a "python" executable (symlink to python3), for fear of breaking their system.
What is the recommended way of handling this problem?

Mypy setting "follow_import" is ignored

My mypy.ini looks like

[mypy]
python_version = 3.6

[mypy-turbo.*]
follow_imports=skip

And .pycheckers

[DEFAULT]
max_line_length = 160
checkers=flake8, pylint, mypy3

mypy_config_file = /home/kendriu/sources/turbo/mypy.ini

The follow_imports seems to be ignored when pycheckers do it stuff.

Running mypy from command line works as expected (imports are ignored)

mypy2 and mypy3 conflict

By default, since you are including both mypy versions, the warnings and errors conflict. For example:

print "hello world"

passes mypy2 but is invalid syntax in mypy3.

Conversely:

print("hello world")

passes mypy3 but warns of unnecessary parens in mypy2.

Perhaps provide a python version configuration option, or be opinionated about which python version to support by default and pick that one.

Missing error code for flake8 plugins

When using flake8 plugins, the parsing of error codes is lacking:

flycheck-pycheckers/bin/pycheckers.py

Line 538 in 680ed9b

'(?P<error_type>[WEFCNI])(?P<error_number>[^ ]+) '

E.g. flake8-unused-arguments uses code "U", which is missing from the regex.

Given that plugins are free to use whatever codes they want, I wonder if we should accept any letter as "error_type".

Config-file should be .pycheckers

Right now we use the pylint rcfile as the config file for all of flycheck-pycheckers (according to the elisp), which is kind of silly.

flake8 errors missing from *Flycheck errors* buffer

I have pycheckers set up with flake8, mypy, and pylint. I'm not sure when this started happening, but flake8 items no longer appear in the error list. They still show up in the minibuffer though when the cursor is on an offending line:

$ flake8 --version
3.5.0 (mccabe: 0.6.1, pycodestyle: 2.3.1, pyflakes: 1.6.0) CPython 3.6.0 on Darwin

I'm still investigating the underlying cause, but I suspect flake8 may have changed its output format?

---

Test file:

from typing import Type

class A(object): pass
class B(object): pass

a = None  # type: A
a = A()
a = B()

def foo(arg1, arg2):
    return arg1.member, arg2.member

.pycheckers ignore_codes has no effect

I couldn't seem to get the ignore_codes setting from my .pycheckers file to take effect. Example contents:

[DEFAULT]
checkers=pylint
ignore_codes=C0410,C0111

After troubleshooting pycheckers.py, it looks like the issue is caused by inconsistent use of "ignore_codes" vs "ignored_codes". For example, the relevant CLI arg to pycheckers.py is --ignore-codes. This gets parsed into options.ignored_codes. But that means that update_options_locally() would parse the ignore_codes setting from my .pycheckers file into a new options.ignore_codes key. Similar story for the .pycheckers extra_ignore_codes option.

Although I'm not aware of any bugs related to "enable" vs "enabled", it might be a good time to examine that usage as well.

I propose the present tense "ignore" and "enable" be consistently used and all instances of "ignored" and "enabled" be changed. I don't see any issues that would arise due to "ignore". Regarding "enable", the emacs variable flycheck-pycheckers-enabled-codes would be affected.

Incorrect use of "define-obsolete-variable-alias"

The use of define-obsolete-variable-alias is wrong here:

flycheck-pycheckers/flycheck-pycheckers.el

Line 206 in e8ce874

(define-obsolete-variable-alias 'flycheck-pycheckers-enabled-codes 'flycheck-pycheckers-enable-codes)

On Emacs tip, that function requires a third parameter, when:

(define-obsolete-variable-alias OBSOLETE-NAME CURRENT-NAME WHEN &optional
DOCSTRING)

Emacs version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0) of 2021-03-31

iteritems does no longer exists in Python 3

#16

*_command not taken into account when validating whether checker exists

The {}_command parameter is not taken into account when when calling self._executable_exists() in pycheckers.py#L440. It's first considered via self.construct_args(…) which doesn't happen until pycheckers.py#L459. The net effect is that if you're overriding, e.g., mypy_command = /usr/local/bin/mypy-daemon as documented, you still need to have an executable called mypy (or dmypy, depending) somewhere in your path, even if it will never be called. (Consider the work-around where you do something like ln -s /bin/true /usr/local/bin/mypy.)

Way to disable some of sane_default_ignore_codes

Looks like bin/pycheckers.py is declaring an "opinionated" list of safe-to-ignore codes, but I prefer using per-project pylintrc files for this.

It does not look like there is a way to deactivate those defaults (however LintRunner excepts a never given use_sane_defaults parameter defaulting to True. As it's given, it's always True).

I'd propose to completly remove the sane_default_ignore_code from the pycheckers.py file and move them all to the default of flycheck-pycheckers-ignore-codes. It should not change the current behavior, but it would allow one to manually remove them from their emacs configuration. Is it a good idea? I can try to implement it if it looks good.

Mypy merges errors from files with similar names

Given the following directory structure,

.
├── pkg1
│   └── controller.py
└── pkg2
    └── controller.py

flycheck-pycheckers will merge mypy output for the two files named controller.py. Newer versions of mypy have started reporting output for all files involved, and the mypy lint runner, although it attempts to filter them out, doesn't do this correctly. This is exacerbated by the fact that the data dictionary received in fixup_data sometimes contains a full filepath, and sometimes just the filename, within the same run of mypy.

Enabled codes should be handled similarly to ignored ones

We should handle enabled codes similarly to #13.

Some checkers have additive behavior when enabling new error codes via the command line, and some fully replace the list of codes being checked against. We should define a consistent semantic for this, and fully implement it.

Provide configurable binaries/invocation commands

The generic command/get_run_flags options are fairly general, but it may be nice to allow for more customization if necessary. For instance, a company-wide mypy driver script would be nice to support.

Strictier regex to parse mypy errors

This regex is too loose and fails to parse mypy output when no column numbers are shown:

flycheck-pycheckers/bin/pycheckers.py

Line 713 in 5119aa6

r'((?P<column_number>[^:]+):)?' # Column number is optional, depending on mypy options

I would suggest to use instead \d to mean "digits" when line or column numbers are expected:

    output_matcher = re.compile(
        r'(?P<filename>[^:]+):'
        r'(?P<line_number>\d+):'
        r'((?P<column_number>\d+):)?'  # Column number is optional, depending on mypy options
        r' (?P<level>[^:]+):'
        r' (?P<description>.+)$')

Question about virtual environments

I'm using flycheck-pycheckers with a python file and have set the virtual environment appropriately using python-shell-virtualenv-root and flycheck-pycheckers-venv-root is also set correctly.

python-shell-virtualenv-root is a variable defined in ‘python.el’.

Its value is "/Users/rpg/.virtualenvs/ipyhopper/"
Original value was nil

However, flycheck-pycheckers does not seem to see this virtual environment, and complains that modules that are installed in the virtualenv cannot be found.

Is there something I need to do to tell flycheck-pycheckers about the current virtual environment? I see that the command is passed the virtual env root directory as a command line argument, but don't see how it knows which virtual environment in the root it should be using when checking a particular file.

Looking at pycheckers.py, I can see that there's a --venv-path argument, but nothing in flycheck-pycheckers.el uses that argument. Adding the following to my source file seems to work properly:

# Local Variables:
# flycheck-pycheckers-args: ("--venv-path" "/Users/rpg/.virtualenvs/ipyhopper")
# End:

Would it make sense to have a buffer-local variable like flycheck-pycheckers-venv-path that defaults to nil, and is passed to pycheckers.py? If you think this is a reasonable step to take, I could try to make a PR.

Windows flake8 output is different than unixen

See #11 for the motivating report, but we should be able to handle output from Windows-run linters as well as OSX/Linux.

Executable not found on Windows

The Issue

Hello!
When I freshly install the flycheck-pycheckers package and enable it in elpy mode I got the following error whenever I visit a python file:

File mode specification error: (error Command executable for syntax checker python-pycheckers must be a string: nil)

I did my homework

After some investigation on the issue I realized that the flycheck-pycheckers-command variable is nil.
This because the executable-find function seems not to find the pycheckers.py file.
According to the emacs documentation, this command tries to look in all paths found in exec-path variable and to substitute all suffixes found in the exec-suffixes.

On my machine the exec-suffixes is set to: (".exe" ".com" ".bat" ".cmd" ".btm" "")
As the empty string is included I thought it would have found the file, but no luck.

For test purposes I locally modified the offending statement as:

(defvar flycheck-pycheckers-command
  (executable-find (concat (file-name-directory (or load-file-name buffer-file-name))
                           "bin/pycheckers")))

And I added a batch script called pycheckers.bat in the same bin folder, from which I execute the python script:

python "%~dp0pycheckers.py" %*

So I manage to make it work, but I am looking for a more long-term elegant solution to this issue.

Has anybody ever get into this issue?

Cheers,
Samuele

mypy_command and daemon mode

Hello, I've been trying to change the mypy command to a python script I have worked on, but this apparently fails (it keeps calling mypy3). I have additionally tried mypy_use_deamon set to True, and mypy just stops working, as if it was not in the list of checkers. I guess something silently fails.

No unit tests present

As we add more functionality/options, we need a way to make sure we don't regress. Add some unit tests to verify, among others:

• option parsing
• checker execution
• expected errors caught
• ignored errors ignored correctly
• agreement between options supplied by emacs and expected by pycheckers.py