Skip to main content

Static code analysis for buildout-based Python projects.

Project description

Egg Status Travis Build Status Test Coverage Downloads Python Versions Latest Version License


plone.recipe.codeanalysis provides static code analysis for Buildout-based Python projects, including flake8, JSHint, CSS Lint, and other code checks.

This buildout recipe creates a script to run the code analysis:


By default plone.recipe.codeanalysis also creates a git pre-commit hook, in order to run the code analysis automatically before each commit.

plone.recipe.codeanalysis comes with a Jenkins integration, that allows to use the same code analysis settings on your local machine as well as on Jenkins.

It also allows to run code analysis to any arbitrary folder:

bin/code-analysis src/Products.CMFPlone


Just add a code-analysis section to your buildout.cfg:

parts += code-analysis

recipe = plone.recipe.codeanalysis
directory = ${buildout:directory}/src

The directory option is not required. Though, if you don’t specify a directory the code analysis will check every file in your buildout directory.

This configuration is helpful for working on already existing packages. If you create a new package you might want to enable all checks. This configuration looks like this:

recipe = plone.recipe.codeanalysis[recommended]
multiprocessing = True
jenkins = False
directory =
return-status-codes = True
pre-commit-hook = True
# JS
jshint = True
jshint-bin = ${buildout:bin-directory}/jshint
jshint-suppress-warnings = False
jscs = True
jscs-bin = ${buildout:bin-directory}/jscs
jscs-exclude =
csslint = True
csslint-bin = ${buildout:bin-directory}/csslint
zptlint = True
zptlint-bin = ${buildout:bin-directory}/zptlint
# Chameleon uses XML (there is no chameleon-lint-bin, it uses lxml)
chameleon-lint = False
# XML (there is no xmllint-bin, it uses lxml)
xmllint = True
# scss-lint
scsslint = True
scsslint-bin = ${buildout:bin-directory}/scss-lint
# TS
tslint = True
tslint-bin = ${buildout:directory}/bin/tslint
tslint-exclude = ${:jscs-exclude}
# Conventions
clean-lines = True
clean-lines-exclude = ${:jscs-exclude}
# dependency-checker
dependencychecker = True
dependencychecker-bin = ${buildout:directory}/bin/dependencychecker
# i18n
find-untranslated = True
i18ndude-bin = ${buildout:bin-directory}/i18ndude
flake8-exclude =,,docs,*.egg,*.cpy,*.vpy,overrides

recipe = gp.recipe.node
npms = csslint jshint jscs tslint
scripts = csslint jshint jscs tslint

Git hooks

  • pre-commit-hook

  • pre-commit-return-status-codes

  • pre-push-hook

  • pre-push-return-status-codes

You can choose to activate git pre-commit-hook and/or pre-push-hook hooks. You can make these hooks blocking (aborting) by setting return-status-codes to ‘True’. You can tune the return code behavior differently from the default for each hook, using pre-commit-return-status-codes and pre-push-return-status-codes.

What works best for you is a matter of taste, and code base.

If you want to ensure that your working area is always clean on each commit, and you’d like to abort the commit if anything untowards is found, you can configure:

return-status-codes = True
pre-commit-hook = True

If you’re working in a large code base, which takes a long time to parse, and your workflow is to use many small commits, you may be annoyed by the pre-commit delay. Or maybe you like to check in parts of your work, while having other files hanging around in your working tree which aren’t cleaned up yet.

In that case you may want to disable pre-commit checks, and have a blocking pre-push check instead:

return-status-codes = True
pre-commit-hook = False
pre-push-hook = True

Or maybe you want code-analysis by default to run unblocking, to please Jenkins, but still want to have blocking checks on both pre-commit and pre-push? Can do:

return-status-codes = False
pre-commit-hook = True
pre-commit-return-status-codes = True
pre-push-hook = True
pre-push-return-status-codes = True

Yeah I know, it’s a contrived example, but it illustrates the relevant options.

Configuration overrides

The options documented above configure code-analysis at the project level. Sometimes developers may want to deviate from the project-level settings locally, for example to make the git pre-commit hook block on violations, even when the project-wide setting is to not abort the commit on violations.

If for example the project buildout.cfg reads:

overrides = code-analysis-overrides-acmecorp
return-status-codes = False
pre-commit-hook = True

But as a developer I’d rather have a blocking pre-push instead of a nonblocking pre-commit, I can configure overrides in my .buildout/default.cfg configuration as follows:

return-status-codes = True
pre-commit-hook = False
pre-push-hook = True

This is especially handy to let users choose themselves whether they want a pre-commit-hook or a pre-push-hook, and whether they want to block on violations (so they don’t have to amend commits) or whether they want non-blocking checks (so they can have invalid files in their working tree outside the commited c.q. pushed set of files). YMMV.

Note that if a project does not configure overrides at the project level, you can as a dev still configure that in .buildout/default.cfg:

overrides = code-analysis-overrides

return-status-codes = True

The recommended policy is to define an overrides name per project, so devs can tune their overrides per project. Repo-specific override names only make sense if the repo is really different (say much bigger) than typical. Per-project override names would show up in a devs .buildout/default.cfg for example as follows:

return-status-codes = True
pre-commit-hook = True
pre-push-hook = True

<= code-analysis-overrides-plone

return-status-codes = True
pre-commit-hook = False
pre-push-hook = True

For projects that really really want to NOT offer this option to their developers, there’s the simple solution of blocking overrides in the project buildout.cfg:

overrides = False

It’s recommended to actually talk to your fellow devs about which overrides are not acceptable, instead of taking this nuclear option. If a developer disagrees with the set of flake8 extensions you’re validating with, that’s really a social issue, not something that can be solved in code.

A more suble way of controlling what local reconfigurations a dev is allowed to perform is to configure the overrides-allowed whitelist at the project level:

overrides-allowed = multiprocessing

As a result, only the override options listed here will be taken from the developer’s local configuration, all other options will be taken from the project buildout.cfg. Listing an empty overrides-allowed option allows all options to be overridden.

But of course, all of this runs on the developer’s machine…

Jenkins Installation

plone.recipe.codeanalysis provides a Jenkins setting that allows to run it on a Jenkins CI server and to process and integrate the output via the Jenkins Violations plugin.

Usually you don’t want the recipe to create Jenkins output files on your local machine. Therefore it makes sense to enable the Jenkins output only on the CI machine. To do so, just create a jenkins.cfg that extends and overrides the default buildout file (that includes the other settings):

parts += code-analysis

recipe = plone.recipe.codeanalysis
jenkins = True

The Jenkins job itself should run bin/code-analysis:

python -c jenkins.cfg
bin/buildout -c jenkins.cfg
bin/jenkins-test --all

The Jenkins Violations plugin needs to be configured to read the output files generated by this configuration.

pep8 (to read the flake8 output):






jslint (to read the jshint output):


checkstyle (to read the jscs output):


Filesystem output

If jenkins is set to False, you can still store the output on the filesystem by setting flake8-filesystem = True. This is ignored if jenkins is set to True.



Supported options

If you need to bypass checks for some reasons on a specific line you may use # noqa in Python or // noqa in Javascript files. This works for most of our checks.

The recipe supports the following options:


Directory that is subject to the code analysis.


If set to True, the bin/code-analysis script returns an error code that Continuous Integration servers (like Travis CI) can use to fail or pass a job, based on the code analysis output. Note that Jenkins usually does not need this option (this is better handled by the Jenkins Violations plugin). Note that this option does not have any effect on the other code analysis scripts. Default is False.

Note that this option can be overridden command-line by using the --return-status-codes or --no-return-status-codes command-line options.

Note also that the pre-commit and post-commit hooks can be tuned to have a different status code behavior, if wanted, see below.


If set to True, a git pre-commit hook is installed that runs the code analysis before each commit. Default is True.


If set to True, if a pre-commit hook is run it will abort the commit if violations are found. Default value is the value configured for return-status-codes.


If set to True, a git pre-push hook is installed that runs the code analysis before it gets pushed to a remote. Default is False.


If set to True, if a pre-push hook is run it will abort the push if violations are found. Default value is the value configured for return-status-codes.

Note that in general it will be advisable to set this option to True so you will avoid pushing broken work. YMMV.


If set to True, code-analysis will fork multiple processes and run all linters in parallel. This will dramatically increase speed on a multi-core system, specially when using code-analysis as pre-commit hook. Default is False.


If set to True, the code analysis steps will write output files that can be processed by the Jenkins Violations plugin. Default is False.


If set to True, the flake8 code analysis step will write an output file. Ignored if jenkins is True. Default is False.


If set to True, run Flake8 code analysis. Default is True.


Flake8 now takes advantage of flake8 extension system. Default is none. If flake8 is set to False, this option will be ignored. Example to supercharge with some extensions:

recipe = plone.recipe.codeanalysis
flake8 = True
flake8-extensions =

flake8 Settings

Flake8 uses the following files to look for settings:

  • setup.cfg (recommended for Plone)

  • tox.ini

  • .flake8

exclude =,,docs,*.egg
max-complexity = 10
max-line-length = 79
Look at Flake8 documentation

and it’s plugins to see which options are available.


If set to True, check-manifest will be run to check you file. Default is False.


Default is . which means check the current package where you included code-analysis in buildout.

EXPERIMENTAL: For project buildouts where you use several source packages you may want to enter multiple directories or use ${buildout:develop} to include all your development packages.


If set to True, import statement analysis is run and verified against declared dependencies in Default is False.


Set the path to a custom version of dependencychecker.


If set to True, import statement analysis is run and unused imports are reported. Default is False.


Set the path to a custom version of importchecker.


If set to True, jshint code analysis is run. Default is False. Note that plone.recipe.codeanalysis requires jshint >= 1.0.


JSHint executable. Default is jshint. If you have JSHint installed on your system and in your path, there is nothing to do. To install JSHint in your buildout, use the following:

recipe = gp.recipe.node
npms = jshint
scripts = jshint

set jshint-bin to ${buildout:bin-directory}/jshint.


Allows you to specify directories which you don’t want to be linted. Default is none. If you want JSHint to skip some files you can list them in a file named .jshintignore. See JSHint documentation for more details.


By default warnings of jshint are suppressed and not shown. You may disable this by setting to False, default is True for backward compatibility reasons.


If set to True, jscs code analysis is run. Default is False.

JavaScript Code Style options should be configured using a .jscs.json file. You should align your javascript code to the next generation of Plone’s javascript framework Mockup and take it’s .jscs.json file which is available here:

All configuration options are documented on the jscs website.


Set the path to a custom version of JSCS, e.g. /usr/local/bin/jscs.

If you have Javascript Code Style Checker installed in your system and path, you have nothing to do. To install with Buildout, add the following section to your buildout and set jscs-bin to {buildout:bin-directory}/jscs:

recipe = gp.recipe.node
npms = jscs
scripts = jscs

Allows you to specify directories and/or files which you don’t want to be checked. Default is none. Note that these directories have to be given in absolute paths, use ${buildout:directory}/foo/bar/static/js-3rd-party for example.


If set to True, CSS Lint code analysis is run. Default is False.

CSS Lint options should be configured using a .csslintrc file. A typical .csslintrc file will look like this:


This typical configuration includes a list of CSS rules that will be ignored as they are considered useless.

See CSS Lint documentation and CSS Lint command-line interface for a detailed list and description of the rules.


Set the path to a custom version of CSS Lint, e.g. /usr/local/bin/csslint.

If you have CSS Lint installed in your system and path, you have nothing to do. To install CSS Lint with Buildout, add the following section to your buildout and set csslint-bin to {buildout:bin-directory}/csslint:

recipe = gp.recipe.node
npms = csslint
scripts = csslint

Allows you to specify directories and/or files which you don’t want to be checked. Default is none.


If set to True, ChamleonLint code analysis is run. Default is False.

ChameleonLint uses lxml for xml parsing. There is no chameleon-lint-bin.

Note that you will want to activate either chameleon-lint or zpt-lint, not both, since they will apply to the same set of file extensions (.pt, .cpt, .zpt). The zpt-lint parser uses the actual TAL expression engine to validate templates, and this will generally choke on the Chameleon extensions. The chameleon-lint parser on the other hand just checks that the template is valid XML basically.


If set to True, XMLLint code analysis is run. Default is False.

XMLLint uses lxml for xml parsing. There is no xmllint-bin.


If set to True, any file containing trailing spaces or tabs anywhere on the lines will cause a warning. Default is False.


Allows you to specify directories and/or files which you don’t want to be checked. Default is none.

i18ndude, scsslint and zptlint support

To reduce the number of Zope/Plone direct dependencies, plone.recipe.codeanalysis no longer depends on i18ndude nor SCSS Lint nor zptlint; in order to use the following options you have to install them on your system, see buildout.cfg for an example install.


If set to True, scan Zope templates to find untranslated strings. Default is False. To use this you will need to set the i18ndude-bin option.


Allows you to specify directories and/or files which you don’t want to be checked. Default is none.


The report will contain only the errors for each file. Default is False. However, summaries will also be suppressed when jenkins is set to True.


Set the path to a custom version of i18ndude. Default is none.


If set to True, SCSS Lint code analysis is run. Default is True.


Set the path to a custom version of SCSS Lint. Default is none.

Note that you’ll typically install the gem scss_lint (with underscore) to get a bin file scss-lint (with a dash).

If you have SCSS Lint installed in your system and path, you have nothing to do. To install SCSS Lint with Buildout, add the following section to your buildout and set scsslint-bin to {buildout:bin-directory}/scss-lint:

recipe = rubygemsrecipe
gems = scss_lint

Please note that due to some buildout weirdness this will break buildout
on the first buildout run; a second buildout run will complete just fine.


SCSS Lint options can be configured, see SCSS Lint README.


If set to True, zptlint code analysis is run. Default is False. To use this you will need to set the zptlint-bin option.

Note that you will want to use either zptlint or chameleon-lint, not both.


Set the path to a custom version of zptlint. Default is none.


Allows you to specify directories and/or files which you don’t want to be checked. Default is none.

Self-tests for these extra linters are disabled by default. To run a plone.recipe.codeanalysis self-test that covers these extra linters:

TEST_ALL=true bin/test

Known Issues

JSHint “ERROR: Unknown option –verbose”:

JSHint                [ OK ]
ERROR: Unknown option --verbose

Upgrade JSHint to latest version (>= 1.0) to fix this issue, e.g.:

$ sudo npm install -g jshint

JSHint “ERROR: Unknown option –exclude”:

JSHint                [ OK ]
ERROR: Unknown option --exclude

Upgrade JSHint to latest version (>= 2.1.6) to fix this issue, e.g.:

$ sudo npm install -g jshint

Rubygems woes:

Installing rubygems.
rubygems: Extracting package to /app/plone.recipe.codeanalysis/parts
ERROR:  While executing gem ... (Errno::EACCES)
Permission denied @ rb_sysopen - /usr/lib/ruby/gems/2.3.0/specifications/default/bundler-1.16.1.gemspec
rubygems: b''
rubygems: Command failed with exit code 1: ['ruby', 'setup.rb', 'all', '--prefix=/app/plone.recipe.codeanalysis/parts/rubygems', '--no-rdoc', '--no-ri']
Installing rubygems.
Error: System error

Solution: run buildout again. Really.

Tests fail:

Traceback (most recent call last):
File "/app/plone.recipe.codeanalysis/plone/recipe/codeanalysis/", line 18, in <module>
import zc.buildout
ModuleNotFoundError: No module named 'zc.buildout'

This is likely caused by Solution: run:

bin/easy_install -U zc.buildout==2.11.0

before running bin/buildout.

Example usage

Minimal buildout:

>>> write('buildout.cfg',
... """
... [buildout]
... parts = code-analysis
... [code-analysis]
... recipe = plone.recipe.codeanalysis
... directory = %(directory)s
... """ % {
...     'directory' : '${buildout:directory}/plone/recipe/codeanalysis',
... })

Running the buildout gives us a ‘code-analysis’ script that runs the entire code analysis:

>>> buildout_output_lower = system(buildout).lower()
>>> '/sample-buildout/bin/code-analysis' in buildout_output_lower

It is also possible to run single code analysis scripts:

>>> '/sample-buildout/bin/code-analysis-flake8' in buildout_output_lower
>>> '/sample-buildout/bin/code-analysis-jshint' in buildout_output_lower

Flake 8 is installed by the buildout script, there is no need to install it on the system:

>>> '/sample-buildout/bin/flake8' in buildout_output_lower

Pre-commit hook

If we have a git repository:

>>> import subprocess
>>>['mkdir', '-p', '.git/hooks'])

And run buildout again:

>>> buildout_output_lower = system(buildout).lower()

Then the git pre-commit hook is installed:

>>> 'installed git pre-commit hook.' in buildout_output_lower


  • Timo Stollenwerk, Original Author

  • Gil Forcada

  • Héctor Velarde

  • Ramiro Batista da Luz

  • Daniel Widerin

  • Michael Davis

Change history

3.0.1 (2018-06-27)

  • Fix PyPi readme page. [timo]

3.0.0 (2018-06-27)

  • Re-release of 3.0.0a (brown bag release). [timo]

3.0.0a (2018-06-15)

  • Removed flake8 default settings in favor of using setug.cfg [iham]

  • Add XMLLint for .xml .xsl .zcml files. [janjaapdriessen]

  • Add scss-lint for sass files. [janjaapdriessen]

  • Add a XML linter for Chameleon template files. [janjaapdriessen]

  • Work around Travis bootstrapping and coverage failures caused by and, which obscure that the tests are actually green. Mark python3 builds without extras as critical again. Note that this requires a double-buildout sequence to get the scss-lint gem properly installed… Fixes #214. [gyst]

  • Revive XMLLint, and SCSSLint work by janjaapdriessen. Add tests and documentation. [gyst]

  • Replace unmaintained zptlint upstream by spirit.zptlint. [gyst]

  • Add tests for Chameleon Linter and fixup the linter. Fixes #180, sort of; the validation is much less strict than the ZPTLint one. [gyst]

  • Pull in i18ndude python3 fixes and mark EXTRAS tests as critical. [gyst]

  • Update z3c.dependencychecker dependency and provide an analyser for it. No tests for this since it would require a full egg fixture. Fixes #67. [gyst]

  • Add importchecker linter. Fixes #67. [gyst]

  • Post-merge cleanup of source dependencies for the python3 work. [gyst]

  • Introduce overrides to support individual developer preferences. [gyst]

  • Introduce pre-push-hook and allow command-line and githook deviation from default return-status-codes. [gyst]

  • Remove trailing dot from Jenkins output, to ease copy-pasting filenames. [janwijbrand]

  • Bring our own dogfood linter config and version pins in sync with coredev qa.cfg. [gyst]

2.3 (2018-01-18)

  • Install isort script if flake8-isort is installed as well. [gforcada]

  • Add a new recommended flake8 plugin: flake8-commas. [gforcada]

  • Fix Continuous Integration (Travis) by using pip to install setuptools and zc.buildout. [gforcada]

  • Run tests only once on CI. [gforcada]

  • Remove as it is no longer used. [gforcada]

  • Fix code analysis errors. [gforcada]

  • Fix travis (newer setuptools and zc.buildout needed) [gforcada]

  • Check Python 3.5 and 3.6 in travis as well (although they fail currently). [gforcada]

  • Add ‘find-untranslated-no-summary’ option for i18ndude. [tmassman]

2.2 (2016-02-20)

  • Fix issue where commit hook did not work on NixOS (fixed to use /usr/bin/env bash instead /bin/bash). [datakurre]

  • Allow to pass a folder where to run code analysis against. [gforcada]

  • Increase minimum requirement of flake8. Older versions could make checks with exceptions in plugins as passed. [do3cc]

2.1 (2015-09-21)

  • Remove debug statements checker, flake8-debugger, flake8-print and jshint can do the same job. [gforcada]

  • Removed pep3101 checker, flake8-pep3101 works exactly the same. [gforcada]

  • Remove deprecated aliases checker, flake8-deprecated does the same job. [gforcada]

  • Remove hasattr checker, flake8-plone-hasattr does the same job. [gforcada]

  • Add a [recommended] extra to install a set of flake8 plugins, some of them where part of p.r.codeanalysis up until this release. [gforcada]

  • Remove leftovers from utf-8 checker removal. [gforcada]

  • Remove imports checker, flake8-isort does the same job. [tisto] [gforcada]

  • Fix typo on test that prevented ipdb imports from being found. [hvelarde]

2.0.2 (2015-09-03)

  • Less false positives for pep3101. [do3cc]

  • Add --jobs=1 to flake8 if multiprocessing is set to False. [saily]

  • Fix #151 by not instantiating Lock and Value if multiprocessing was set to False. [saily]

2.0.1 (2015-09-02)

2.0 (2015-08-07)

2.0b1 (2015-05-03)

2.0a2 (2015-04-30)

  • Replace manual comparisons of buildout options to False with a bool_option method. [saily]

  • Removed some plugins and replaced them with flake8 plugins. Please not the API change in buildout. Following options have been removed:

    • utf8-headers has been removed, replace it with flake8-coding if needed.

    • utf8-headers-exclude

    • prefer-single-quotes has been removed, replace it with flake8-quotes.

    • prefer-single-quotes-exclude

    • debug-statements has some reduced functionality, because python debugger checks should be included using flake8-debugger extension which also checks for ipdb.

    Fixes [saily]

  • Add missing tests for deprecated_aliases parser. [saily]

  • Add new double quotes parser and add test for it. It now also supports # noqa statments and nested quotes. [saily]

2.0a1 (2015-04-27)

1.1 (2014-12-04)

  • Add a check to look for hasattr() calls, which are considered bad practice. [gforcada, jensens]

  • Add option to store flake8 output if jenkins is False [Michael Davis]

  • Fix find_files from utils to find files, not directories [do3cc]

1.0 (2014-12-04)

  • Nothing changed since 1.0rc1.

1.0rc1 (2014-06-18)

  • Return a string to avoid TypeError when no file was checked with jscs. [saily]

  • Check import sorting in code_analysis_imports and add tests for clean and sorted imports. [saily]

  • Refactor code_analysis_clean_lines to use a new method to retrieve files and avoid too complex violation. [saily]

1.0b8 (2014-06-05)

1.0b7 (2014-05-04)

  • Add Javascript Code Style Checker jscs support. [saily]

  • Remove hard dependency on i18ndude and zptlint; this will reduce the number of Zope/Plone direct dependencies to make life happier to people using Pyramid and other web Python-based development frameworks. Fixes [hvelarde]

  • Do not print out jshint and csslint output for Jenkins. Those files can become quite large. [timo]

1.0b6 (2013-10-16)

  • Remove progress bullets from flake8 check. [timo]

  • Improve the way to handle an exception if the command used in popen does not exist. [flohcim]

1.0b5 (2013-10-08)

  • Fix code analysis method by making it call each check only if the option is activated. [flohcim]

  • Keep backward compatibility with ‘string-formatting’ option. [hvelarde]

  • Rename ‘deprecated-alias’ to ‘deprecated-aliases’ and keep backward compatibility. [hvelarde]

1.0b4 (2013-10-06)

  • Implement Jenkins option on CSS Lint and JSHint. [hvelarde, ramiroluz]

  • Rename ‘deprecated-methods’ to ‘deprecated-alias’. [gforcada]

  • Rename ‘string-formatting’ option to ‘pep3101’ to keep consistency. [hvelarde]

  • Remove unused CSSLINT_IGNORE remainings. [timo]

  • Simplify code analysis method and make it more readable. [timo]

1.0b3 (2013-09-12)

  • Add return-status-codes option that allows to fail a CI-build on Travis. [timo]

  • Make system wide installed csslint the default value for the csslint-bin option. [timo]

1.0b2 (2013-09-11)

  • Deprecate ‘csslint-quiet’, ‘csslint-ignore’ and ‘csslint-exclude-list’ options; CSS Lint must be configured now using a ‘.csslintrc’ file. ‘csslint-bin’ option now defaults to bin/csslint; documentation was updated (closes #20). [hvelarde]

  • Implement removal of pre-commit hook. Fixes [hvelarde]

1.0b1 (2013-08-12)

1.0a1 (2013-08-04)

  • Initial release. [timo]

Project details

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

plone.recipe.codeanalysis-3.0.1.tar.gz (66.9 kB view hashes)

Uploaded Source

Supported by

AWS AWS Cloud computing and Security Sponsor Datadog Datadog Monitoring Fastly Fastly CDN Google Google Download Analytics Microsoft Microsoft PSF Sponsor Pingdom Pingdom Monitoring Sentry Sentry Error logging StatusPage StatusPage Status page