A tool that executes a suite of static analysis tools upon a Python project.
TidyPy is a tool that encapsulates a number of other static analysis tools and makes it easy to configure, execute, and review their results.
- It’s a consolidated tool for performing static analysis on an entire Python project – not just your *.py source files. In addition to executing a number of different tools on your code, it can also check your YAML, JSON, PO, POT, and RST files.
- Rather than putting yet another specialized configuration file in your project, TidyPy uses the pyproject.toml file defined by PEP 518. All options for all the tools TidyPy uses are declared in one place, rather than requiring that you configure each tool in a different way.
- Honors the pseudo-standard # noqa comment in your Python source to easily ignore issues reported by any tool.
- Includes a number of integrations so you can use it with your favorite toolchain.
- Includes a variety out reporters that allow you to view or use the results of TidyPy’s analysis in whatever way works best for you.
- Provides a simple API for you to implement your own tool or reporter and include it in the analysis of your project.
- Supports both Python 2 and 3, as well as PyPy. Even runs on Windows.
When TidyPy is installed (pip install tidypy), the tidypy command should become available in your environment:
$ tidypy --help Usage: tidypy [OPTIONS] COMMAND [ARGS]... A tool that executes several static analysis tools upon a Python project and aggregates the results. Options: --version Show the version and exit. --help Show this message and exit. Commands: check Executes the tools upon the project files. default-config Outputs a default configuration that can be used to bootstrap your own configuration file. extensions Outputs a listing of all available TidyPy extensions. install-vcs Installs TidyPy as a pre-commit hook into the specified VCS. list-codes Outputs a listing of all known issue codes that tools may report. purge-config-cache Deletes the cache of configurations retrieved from outside the primary configuration. remove-vcs Removes the TidyPy pre-commit hook from the specified VCS.
To have TidyPy analyze your project, use the check subcommand:
$ tidypy check --help Usage: tidypy check [OPTIONS] [PATH] Executes the tools upon the project files. Accepts one argument, which is the path to the base of the Python project. If not specified, defaults to the current working directory. Options: -x, --exclude REGEX Specifies a regular expression matched against paths that you want to exclude from the examination. Can be specified multiple times. Overrides the expressions specified in the configuration file. -t, --tool [2to3|bandit|eradicate|jsonlint|manifest|mccabe|polint|pycodestyle|pydiatra|pydocstyle|pyflakes|pylint|pyroma|rstlint|secrets|vulture|yamllint] Specifies the name of a tool to use during the examination. Can be specified multiple times. Overrides the configuration file. -r, --report [console|csv|json|null|pycodestyle|pylint|toml|yaml] Specifies the name of a report to execute after the examination. Can be specified multiple times. Overrides the configuration file. --workers NUM_WORKERS The number of workers to use to concurrently execute the tools. Overrides the configuration file. --disable-merge Disable the merging of issues from various tools when TidyPy considers them equivalent. Overrides the configuration file. --disable-progress Disable the display of the progress bar. --disable-noqa Disable the ability to ignore issues using the "# noqa" comment in Python files. --disable-config-cache Disable the use of the cache when retrieving configurations referenced by the "extends" option. --help Show this message and exit.
If you need to generate a skeleton configuration file with the default options, use the default-config subcommand:
$ tidypy default-config --help Usage: tidypy default-config [OPTIONS] Outputs a default configuration that can be used to bootstrap your own configuration file. Options: --pyproject Output the config so that it can be used in a pyproject.toml file. --help Show this message and exit.
If you’d like to see a list of the possible issue codes that could be returned, use the list-codes subcommand:
$ tidypy list-codes --help Usage: tidypy list-codes [OPTIONS] Outputs a listing of all known issue codes that tools may report. Options: -t, --tool [2to3|bandit|eradicate|jsonlint|manifest|mccabe|polint|pycodestyle|pydiatra|pydocstyle|pyflakes|pylint|pyroma|rstlint|secrets|vulture|yamllint] Specifies the name of a tool whose codes should be output. If not specified, defaults to all tools. -f, --format [toml|json|yaml|csv] Specifies the format in which the tools should be output. If not specified, defaults to TOML. --help Show this message and exit.
If you want to install or remove TidyPy as a pre-commit hook in your project’s VCS, use the install-vcs/remove-vcs subcommands:
$ tidypy install-vcs --help Usage: tidypy install-vcs [OPTIONS] VCS [PATH] Installs TidyPy as a pre-commit hook into the specified VCS. Accepts two arguments: VCS: The version control system to install the hook into. Choose from: git, hg PATH: The path to the base of the repository to install the hook into. If not specified, defaults to the current working directory. Options: --strict Whether or not the hook should prevent the commit if TidyPy finds issues. --help Show this message and exit. $ tidypy remove-vcs --help Usage: tidypy remove-vcs [OPTIONS] VCS [PATH] Removes the TidyPy pre-commit hook from the specified VCS. Accepts two arguments: VCS: The version control system to remove the hook from. Choose from: git, hg PATH: The path to the base of the repository to remove the hook from. If not specified, defaults to the current working directory. Options: --help Show this message and exit.
If you’d like to enable bash completion for TidyPy, run the following in your shell (or put it in your bash startup scripts):
$ eval "$(_TIDYPY_COMPLETE=source tidypy)"
In addition to ignoring entire files, tools, or specific issue types from tools via your configuration file, you can also use comments in your Python source files to ignore issues on specific lines. Some tools have their own built-in support and notation for doing this:
- pylint will respect comments that look like: # pylint
- bandit will respect comments that look like: # nosec
- pycodestyle will respect comments that look like: # noqa
- pydocstyle will also respect comments that look like: # noqa
- detect-secrets will respect comments that look like: # pragma: whitelist secret
TidyPy goes beyond these tool-specific flags to implement # noqa on a global scale for Python source files. It will ignore issues for lines that have the # noqa comment, regardless of what tools raise the issues. If you only want to ignore a particular type of issue on a line, you can use syntax like the following:
# noqa: CODE1,CODE2
Or, if a particular code is used in multiple tools, you can specify the exact tool in the comment:
# noqa: pycodestyle:CODE1,pylint:CODE2
Or, if you want to ignore any issue a specific tool raises on a line, you can specify the tool:
# noqa: @pycodestyle,@pylint
You can, of course, mix and match all three notations in a single comment if you need to:
# noqa: CODE1,pylint:CODE2,@pycodestyle
You can disable TidyPy’s NOQA behavior by specifying the --disable-noqa option on the command line, or by setting the noqa option to false in your configuration file. A caveat, though: currently pycodestyle and pydocstyle do not respect this option and will always honor any # noqa comments they find.
Out of the box, TidyPy includes support for a number of tools:
- Pylint is a Python source code analyzer which looks for programming errors, helps enforcing a coding standard and sniffs for some code smells.
- pycodestyle is a tool to check your Python code against some of the style conventions in PEP 8.
- pydocstyle is a static analysis tool for checking compliance with Python docstring conventions (e.g., PEP 257).
- Pyroma tests your project’s packaging friendliness.
- Vulture finds unused code in Python programs.
- Bandit is a security linter for Python source code.
- Eradicate finds commented-out code in Python files.
- Pyflakes is a simple program which checks Python source files for errors.
- Ned Batchelder’s script to check the McCabe cyclomatic complexity of Python code.
- A part of the demjson package, this tool validates your JSON documents for strict conformance to the JSON specification, and to detect potential data portability issues.
- The yamllint tool, as its name implies, is a linter for YAML files.
- The restructuredtext-lint tool, as its name implies, is a linter for reStructuredText files.
- A part of the dennis package, this tool lints PO and POT files for problems.
- Uses Python’s lib2to3 module to find code that should be changed in order to be compatible with Python 3. This tool is disabled by default when executing on Python 3, but you can forcefully enable it in your configuration if you want.
- Uses the check-manifest script to detect discrepancies or problems with your project’s MANIFEST.in file.
- pydiatra is yet another static checker for Python code.
- The detect-secrets tool attempts to find secrets (keys, passwords, etc) within a code base.
TidyPy includes a number of different methods to present and/or export the results of the analysis of a project. Out of the box, it provides the following:
- The default reporter. Prints a colored report to the console that groups issues by the file they were found in.
- Prints a report to the console that is in the same format as Pylint’s default output.
- Prints a report to the console that is in the same format as pycodestyle’s default output.
- Generates a JSON-serialized object that contains the results of the analysis.
- Generates a YAML-serialized object that contains the results of the analysis.
- Generates a TOML-serialized object that contains the results of the analysis.
- Generates a set of CSV records that contains the results of the analysis.
TidyPy includes a handful of plugins/integrations that hook it into other tools.
- TidyPy can be run during execution of your pytest test suite. To enable it, you need to specify --tidypy on the command line when you run pytest, or include it as part of the addopts property in your pytest config.
- TidyPy can be run during execution of your nose test suite. To enable it, you can either specify --with-tidypy on the command line when you run nose, or set the with-tidypy property to 1 in your setup.cfg.
- TidyPy can be included in your PBBT scripts using the tidypy test. To enable it, you can either specify --extend=tidypy.plugin.pbbt on the command line when you run PBBT, or set the extend property in your setup.cfg or pbbt.yaml to tidypy.plugin.pbbt.
- TidyPy can be invoked via the setup.py of your project. Just execute python setup.py tidypy.
A simple interface exists for extending TidyPy to include more and different tools and reporters. When the API settles down, I’ll document it here.
- Aren’t there already tools like this?
- Yup. There’s prospector, pylama, flake8, and ciocheck just to name a few. But, as is customary in the world of software development, if the wheel isn’t as round as you’d like it to be, you must spend countless hours to reinvent it. I’ve tried a number of these tools (and even contributed to some), but in the end, I always found something lacking or annoying. Thus, TidyPy was born.
- How do I run TidyPy on a single file?
- The short answer is, you don’t (at the moment, anyway). It wasn’t designed with that use case in mind. TidyPy was built to analyze a whole project, and show you everything.
- I tried TidyPy out on my project and it reported hundreds/thousands of issues. My ego is now bruised.
Yea, that happens. The philosophy I chose to follow with this tool is that I didn’t want it to hide anything from me. I wanted its default behavior to execute every tool in its suite using their most obnoxious setting. Then, when I can see the full scope of damage, I can then decide to disable specific tools or issues via a project-level configuration. I figured if someone took the time to implement a check for a particular issue, they must think it has some value. If my tooling hides that from me by default, then I won’t be able to gain any benefits from it.
In general, I don’t recommend starting to use linters or other sorts of static analyzers when you think you’re “done”. You should incorporate them into your workflow right at the beginning of a project – just as you would (or should) your unit tests. That way you find things early and learn from them (or disable them). It’s much less daunting a task to deal with when you address them incrementally.
Contributions are most welcome. Particularly if they’re bug fixes! To hack on this code, simply clone it, make sure you have Pipenv installed (it’s a great tool, you should use it even if you’re not working on this project), and then run make setup. This will create a virtualenv with all the tools you’ll need. The Makefile also has a test target for running the pytest suite, and a lint target for running TidyPy on itself.
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|Filename, size & hash SHA256 hash help||File type||Python version||Upload date|
|tidypy-0.7.0-py2.py3-none-any.whl (61.6 kB) Copy SHA256 hash SHA256||Wheel||py2.py3|
|tidypy-0.7.0.tar.gz (50.0 kB) Copy SHA256 hash SHA256||Source||None|