Contributing to the core

To contribute to the core, you need to clone the Lantz repository first.

Version control system

Lantz uses Git as version control system.

There are always at least two branches:
  • master: appropriate for users. It must always be in a working state.
  • develop: appropriate for developers. Might not be in a working state.

The master branch only accepts atomic, small commits. Larger changes that might break the master branch should happen in the develop branch . The develop branch will be merged into the master after deep testing. If you want to refactor major parts of the code or try new ideas, create a dedicated branch. This will merged into develop once tested.

The easiest way to start hacking Lantz codebase is using a virtual environment and cloning an editable package.

Assuming that you have installed all the requirements described in Installation guide, in OSX/Linux:

$ pip-3.4 install virtualenv
$ cd ~
$ virtualenv -p python3.4 --system-site-packages lantzenv
$ cd lantzenv
$ source bin/activate

and in Windows:

C:\Python34\Scripts\pip install virtualenv
cd  %USERPROFILE%\Desktop
C:\Python34\Scripts\virtualenv --system-site-packages lantzenv
cd lantzenv\Scripts

and then install an editable package from Lantz at Github:

$ pip install -e git+git://

You will find the code in ~/lantzenv/src/lantz (OSX/Linux) or %USERPROFILE%\Desktop\lantzenv\src\lantz (Windows).

File system structure

The distribution is organized in the following folders:


Documentation in reStructuredText format with Sphinx makefile. Files must have a .rst extension

To generate, for example, HTML documentation change into this folder and run:

$ make html

You will find the generated documentation in docs/_build/html/index.html


Root folder for the examples.


Root folder containing the core functionality


There is a package folder for each manufacturer and module file for each instrument model (or family of models). All files are named using lowercase. Class drivers are named according to the model. If the model starts with a number, then the first letter of the manufacturer should be prefixed. Finally, all classes should be imported in the of the corresponding package.


Instrument simulators


User interface related code.


Python scripts to provide simple command line functionality.


Test cases.

Python style

  • Unless otherwise specified, follow PEP 8 strictly.
  • Document every class and method according to PEP 257.
  • Before submitting your code, use a tool like and to check for style.
  • Feat and DictFeat should be named with a noun or an adjective.
  • Action should be named with a verb.
  • Files should be utf-8 formatted.

Submitting your changes

Changes must be submitted for merging as pull requests.

Before doing so, please check that:
  • The new code is functional.
  • The new code follows the style guidelines.
  • The new code is documented.
  • All tests are passed.
  • Any new file contains an appropriate header.
  • You commit to the head of the appropriate branch (usually develop).

Commits must include a one-line description of the intended change followed, if necessary, by an empty line and detailed description..

Finally, we have a small Zen

import this
Lantz should not get in your way.
Unless you actually want it to.
Even then, python ways should not be void.
Provide solutions for common scenarios.
Leave the special cases for the people who actually need them.
Logging is great, do it often!