Contributing to LXDock

Here are some simple rules & tips to help you contribute to LXDock. You can contribute in many ways!

Contributing code

The preferred way to contribute to LXDock is to submit pull requests to the project’s Github repository. Here are some general tips regarding pull requests.


Keep in mind that you should propose new features on the project’s issue tracker before starting working on your ideas!

Development environment

You should first fork the LXDock’s repository and make sure that LXD is properly installed on your system. Then you can get a working copy of the project using the following commands (eg. using Python 3.6):

$ git clone<username>/lxdock.git
$ cd lxdock
$ python3.6 -m venv ./env && . ./env/bin/activate
$ make install

Instead of setting up an environment directly on your development machine itself, you can also use the included Vagrantfile for creating a test environment:

$ vagrant up
$ vagrant ssh
$ make coverage

Coding style

Please make sure that your code is compliant with the PEP8 style guide. You can ignore the “Maximum Line Length” requirement but the length of your lines should not exceed 100 characters. Remember that your code will be checked using flake8 and isort. You can use the following commands to perform these validations:

$ make lint
$ make isort


$ tox -e lint
$ tox -e isort


You should not submit pull requests without providing tests. LXDock relies on pytest: py.test is used instead of unittest for its test runner but also for its syntax. So you should write your tests using pytest instead of unittest and you should not use the built-in TestCase.

You can run the whole test suite using the following command:

$ py.test

Code coverage should not decrease with pull requests but in some cases we realise that isn’t always possible. If this happen it should be discussed on a Github issue with the maintainers, so that there is a record of it.

You can easily get the code coverage of the project using the following command:

$ make coverage

Using the issue tracker

You should use the project’s issue tracker if you’ve found a bug or if you want to propose a new feature. Don’t forget to include as many details as possible in your tickets (eg. tracebacks if this is appropriate).