checker information

checks : I guess this is where I configure pylint checks, etc,. What is the list of checks I can use ?

The list of checkers is not handy to obtain, I admit. A quick way can bot to grep the apycotbot/checkers directory:

% grep -r "id =" checkers/chk* checkers/chks_debian.py: id = 'debian_lint' checkers/chks_debian.py: id = 'debian_piuparts' checkers/chks_debian.py: id = 'debian_dpkgdeb' checkers/chks_debian.py: id = 'ldi_upload' checkers/chks_html.py: id = 'html_tidy' checkers/chks_pkg.py: id = 'pkg_doc' checkers/chks_pkg.py: id = 'lgp_check' checkers/chks_pt.py: id = 'pt_syntax' checkers/chks_python.py: id = 'python_syntax' checkers/chks_python.py: id = 'python_unittest' checkers/chks_python.py: id = 'python_pytest' checkers/chks_python.py: id = 'python_lint' checkers/chks_python.py: id = 'python_test_coverage' checkers/chks_python.py: id = 'python_check' checkers/chks_rest.py: id = 'rest_syntax' checkers/chks_xml.py: id = 'xml_well_formed' checkers/chks_xml.py: id = 'xml_valid'

Note that lgp [1] and ldi [2] references two other projects of Logilab. Not sure you will be interested by these checks for now.

Concerning the python checkers (chks_python.py):

• python_syntax is the simplest one: only try to compile all *.py
• python_unittest spawn unittest run for test or tests directory in the root of your project
• python_pytest invokes python_unittest with pytest command [3]
• python_test_coverage tries to make a coverage report using pycoverage
• python_lint runs pylint evaluation
• python_check runs pychecker which is another good code evaluation tool

Another thing, you have to check the need_preprocessor attribute that determine a further entry point for the apycot configuration.

The available options for each check are not documented and you need to look into code to discover them :-( Then, checks can be configured later in the config field (see the configuration field explanation below).

No real API exists, only the _run() method which is responsible of returning check status.

preprocessors : what is the list of preprocessors I can use ?

In the same manner of the checkers:

% grep -r "id =" preprocessors/pp\*
preprocessors/pp_buildeb.py:    id = 'lgp_build'
preprocessors/pp_make.py:    id = 'make'
preprocessors/pp_setup.py:    id = 'set_python_env'
preprocessors/pp_setup.py:    id = 'setup_install'
preprocessors/pp_zope_install.py:    id = 'zope_install'

Basically, you will only need to use the setup_install preprocessor. In this case, you must add the following line in the 'preprocessor' field of your apycot configuration:

install=setup_install

You can see some examples in the cubicweb.org forge: http://www.cubicweb.org/ProjectApycotConfig : apycot config http://www.cubicweb.org/ApycotConfigGroup : apycot group config

> What is the difference between an apycot config and an apycot group ?
> The configuration parameters looks exactly the same.

Historically, we had only apycot config to set a test config for one project. But the duplicates of configuration are so frequent that it's handy to include several apycot group config in project config by using the relation 'use group' (think generic tests).

We have a lot to do to clarify attributes from the legacy version of Apycot. Here is a brief comment about the tedious ones:

• vcs_path is an artefact of the checkout/clone action. Indeed, this operation create a new directory entry (which is often the basename of the vcs_repository)

• checks field is a list of an unordered list of checks

• preprocessors are kind of checks dedicated to set up an environment. It's not clear (at least for me) why we don't rewrite them to real checks but for now 2 limitations can explain it: - we need to create a persistent environment (tmpdir) for running tests - checks cannot be chained efficiently between them (for now)

• environment: set environ variables for your checkers

• configuration field is use to influence the checks behaviour for example, python_lint_threshold=7 changes the new threshold of the pylint checker. The naming schema is :

  <checker_id>_<option_checker> = <new value>

• vcs_repository: vcs ressource of the project but note that actually the remonte support can by broken for some utilities (ex: apycot-changes)

Hope it will help,

[1] http://www.logilab.org/project/logilab-devtools [2] http://www.logilab.org/project/debinstall [3] pytest is our testsuite launcher available in logilab.common