Vermin configuration file

Many tools support loading configuration from config files in addition to command line arguments (e.g. flake8, mypy, pytest). It would be good if vermin can also do this. In some sense, declaring project configuration in a config file is more clear and discoverable than saving command line arguments in a script or Makefile, and is much better than typing out the command line arguments manually in the long term.

Proposed config file name and format

• Many tools have chosen the INI format, and put all configuration items in one specific section. For vermin the file name could be vermin.ini and the section name could be vermin.
• Tools tend to look for multiple files to find configuration (e.g. toolname.ini, setup.cfg, tox.ini and such). This allows a project to put configuration for different tools in different sections in a single file like setup.cfg. For vermin, it is a good start to only look at vermin.ini, and this may be extended in the future.
• Tools may look for a config file in the “containing directory” of processed files and the parent directories. For vermin, to simplify, it is a good start to only look at the current working directory (assuming users are running vermin in project root), and this may be extended in the future.

Here is a sample vermin.ini:

[vermin]
# declaring minimum compatible version in a config file is good
target = 3.4

# key names in the INI file can be the same as the "long form" argument name in CLI
exclude = foo.bar.baz
backport = argparse,typing

# alternative way to express arrays:
backport =
    argparse
    typing
# this is supported by flake8 and pytest, not sure how INI format handles arrays

feature = fstring-self-doc

Configuration priority

• When using CLI, manually passed command line arguments override the items in the config file
• When using the Python API, we may have two options:
  • Don’t read the config file at all
  • Manually passed config objects override the items in the config file (Does it make sense to look for a config file in the current working directory? We’re passing code strings and not dealing with any files.)

Finally, it could be good to print a verbose message like “loading configuration from file …” when a configuration file is discovered and used. This will let users know that a config file is in effect and help them diagnose configuration problems.

[gousaiyang]

Looks good

[gousaiyang]

Oh for the --exclude-file parameter, I’ve misunderstood its meaning. I thought it is excluding certain files from analysis rather than reading --exclude args from a file (instead of from CLI). Excluding certain files from analysis could be useful to some extent, if a project has some files with .py extension which are test cases (data) for static analysis rather than code to be executed.

As for vermin.ini detection in subfolders, I thinks it’s fine not to check all subfolders based on file paths specified in sys.argv. The user can easily specify the config file in the subfolder via --config-file, or simply do a chdir before executing vermin. And it’s fine to only recognize one config file instead of allowing multiple config files (and the one in the subfolder overrides the one in the root folder). Otherwise the design would be complicated.