How to Develop

Clone the repository:

$ hg clone
$ cd tryton-env

Make your modification. Submit your change for review:

$ curl -L -o ~/.local/bin/
$ python ~/.local/bin/

Report an Issue

  • Test your issue on the latest development version.
  • Create an issue in our issue tracker.
  • Set the affected components on the issue.
  • Assign the issue to you and set the status to in-progress.
warning If it is a security issue, be careful to correctly set the type to security. This way, the issue will only be visible to the security team until its release.

Submit a Change

  • Follow the coding guidelines.
  • Submit your change to our review tool using the script (see the help page).
  • Make sure the review has the repository name at the start of the review title, and ensure the review description contains a reference to the issue (e.g.: issue1234).
  • Ensure you did not break the tests by running them and add tests if necessary.
  • Once accepted your review will be validated with a LGTM comment from a core developer
  • Your change will then be committed and pushed by a core developer. The commit message will be the review subject (with repository name stripped) and the review description. The reference to the review (e.g.: review123456) will be automatically added to the commit message.
  • Close the review once your change has been applied.
warning If it is a security issue, be careful to mark the review as private.

Coding Guidelines

The Tryton Project strongly recommends the following guidelines.

Code Style


Code style, in general, follows PEP 8:

  • Use 4 spaces for indentation.
  • Avoid the usage of from M import *.
  • If unsure about conformity use flake8 to check the code (with option ignore=E123,E124,E126,E128,E741,W503).
  • Breaking lines:
    • Use 4 spaces per bracket pair.
    • Prefer parenthesis over backslash.


  • Use 4 spaces for indentation.
  • No 80 columns limitation.
  • Opening tag on single line or one attribute per line.

Best Practices

  • Use doc-strings and comments in your code.
  • Never pass keyword arguments as positional arguments when calling a method.
  • In the very beginning (right under the doc-string) of a method definition, define all pool objects that will be used (pool.get(...)).

Naming of modules, classes, variables

  • A name should be as descriptive and as short as possible.
  • Avoid unnecessary duplication of names.
  • Naming structure of a model or module must follow these rules:
    • First part of the name is the general function of the module or model,
    • after this come the less general parts of the name (i.e. the more specific name parts) for the module or model
    • If you are unsure with naming, please ask first on the #tryton channel
  • For modules and method names use an underscore to separate the parts of name.
  • For naming classes use CamelCase.


Your contribution must meet the following requirements:


  • By submitting a change, the contributor accepts the Developer Certificate of Origin.
  • The contributor email must be a valid email address.
  • The domain of the contributor email must not contain tryton.
  • The username of a mercurial changeset must be in the form:
    Name <email>

Nice to have, but not required

  • The contributor name should be the real name of the natural person who submits the code.
  • The contributor email should be linked to only one contributor name.


If the contributor has a significant amount of code, he can add himself to the COPYRIGHT file.

Core developers are people which have push access to the repositories. They are allowed to push small fixes without review. Bigger fixes need approval from other core developers.

In the case of disagreement, a consensus should be reached. As a last resort, the project leader (Cédric Krier) will make the decision.

Publish a Change

This part is only for core developers

warning Always keep the environment repository up to date with all the subrepos:

$ hg commit -S --cwd tryton-env

Push to the remote server:

$ hg push ssh://
Sometimes the push is rejected because it creates a new head. This happens because your local repository is not up to date.
We prefer rebase over merge because it creates a linear history:
$ hg pull --rebase


A fix will be back ported to older series by the maintainer on his own discretion after 1 week in the development branch. The decision is based on the importance of the bug, the availability of workaround and the feasibilities.

Those rules don't apply for security bugs which are applied at once to all affected series and followed by a release.