Contribution guidelines

Version control and workflow

The project is available on GitHub at

As far as workflow is concerned, we’re using standard GitHub pull requests and issues, and that’s it!

If you’re submitting a bugfix, we’d appreciate if you could also fill in an issue, because it’s more visible to other users.

If you want to know if we’d be interested in some improvements, just fill an issue.

Technical policy

Licensing and credits

Please add the standard MPL 2.0 header on any new files you’d contribute.

Don’t forget to add yourself to the Credits page! (unless you don’t want to).

Code style

We’re using flake8 with its default settings. This is enforced by the Travis CI system that runs on pull requests.

To check by yourself:

pip install flake8
flake8 anyblok_wms_base

We also recommend using the flake8 Git pre-commit hook.

Tests coverage

Global coverage

The global tests coverage has been at 100% for almost all the history of the project, it’s checked by the continuous integration, and it must stay this way.

Don’t worry, we’ll help you getting your pull request to that level.

Of course, It doesn’t prove that all important situations are really tested, but we see it the other way around: a line uncovered is certainly not tested! In any case, full tests coverage allows us to very quickly pinpoint problems during refactorings.

self-coverage of subpackages

The self-coverage of some Python packages of this project have also been at 100% for a fair amount of time, and it’s been really great for refactorings.

This means that running the tests of some Blok or subpackage gives 100% coverage of that package.

Ideally, we’d like it to stay that way, but it’s not readily enforced by the current continuous integration systems.

This is currently true for


There’s a special case for the forthcoming wms-inventory Blok. Since it has functionality that depends on whether wms-reservation is installed or not, full coverage can only be achieved by runnig the tests twice, one without wms-reservation and one with it. Of course does precisely this.

We expect more similar cases to appear in the future.

Launching the tests

Common requirements

  • make sure you have a local PostgreSQL server running, with the standard command-line interface (psql), accepting requests on UNIX Socket Domain (this is the default in most installations)

  • make sure that your current system user has a corresponding PostgreSQL role under peer authentication. This is typically ensured by something like:

    sudo -u postgres createuser -dSR `whoami`
  • you’ll need a virtual environment:

    python3 -m venv /path/to/virtualenv
    source /path/to/virtualenv/bin/activate
  • it’s necessary to install AnyBlok / Wms Base in the virtualenv, so that its Bloks are registered. From your Git clone, just do:

    pip install -e .

Launching all the tests

To run all the tests (it takes about one or two minutes depending on your development rig) from your Git clone:


The tests run on a dedicated database that is created afresh each time.

Launching only tests for a Blok, or a Blok sub package

Just do, e.g:

./ wms-core

or for just a subpackage:

./ wms-core --subpkg physobj

for more options:

./ --help

The script ends with a coverage report and instructions on how to rerun more precise tests:

$ ./ wms-core --subpkg physobj
Name                                        Stmts   Miss  Cover
anyblok_wms_base/core/physobj/       7      0   100%
anyblok_wms_base/core/physobj/         241      0   100%
anyblok_wms_base/core/physobj/          99      0   100%
TOTAL                                         347      0   100%
Ran 38 tests in 3.200s


For HTML coverage report, open file:///tmp/COVER-anyblok_wms_base.core.physobj/index.html

To run again with different options, maybe incompatible with the Nose plugin, or a precise test, do something based on:
    anyblok_nose --db-driver-name postgresql --db-name test_awb_anyblok_wms_base.core.physobj -- anyblok_wms_base.core.physobj