Starting contributing to EDM

This section documents the practices used for EDM development

Setting up a development environment

The first step to work on EDM is setting up a dev environment. A simple way to get started is through a virtualenv:

$ git clone edm-git && cd edm-git
$ virtualenv .env && source .env/bin/activate
# EDM's requires a recent setuptools
$ pip install -U pip setuptools
$ pip install -r dev_requirements.txt
$ pip install -e .


when installing EDM From source, the edm entry point is not created, to allow developing EDM within an EDM environment. As such, when developing on EDM you need to invoke EDM As python -m edm.

At this stage, you should be able to run EDM:

$ python -m edm --version
edm 0.6.0.dev491-gitec79824 from /home/davidc/src/enthought/edm-git/edm (cpython 2.7.11)


by default, EDM uses ~/.edm as its root directory only for release versions. To avoid bad surprises, it uses a different default for unreleased versions: in that case, it becomes <edm dir>/.edm where <edm dir> is dirname(edm.__file__). IOW, .edm is created in the source directory. In doubt, you can always know the default directory with:

$ python -m edm info

To run the tests for EDM, do:

$ haas -v edm

Coding philosophy

A few core tenants of developing on EDM:

  • never push into master, every development needs to happen through PRs

  • we follow pep8 for the code, and the numpy style guide for docstring

  • code must be python 2.7 and python 3 compatible (3.4 or above). For 2/3 compatibility, we use six.

PR review practices

  • every PR must pass the tests on travis-ci and jenkins (where os x, windows and linux are tested), unless explicitly stated otherwise by the Project Manager (David)

  • ensure tests pass locally before pushing to the remote: we have a tox setup to check python2, python3, and flake8

  • when creating a PR, please make sure to:

    • assign a milestone to it.

    • assign a reviewer to it.

  • every PR must be reviewed, and have the signoff of either Nora, Simon or David. That list will expand as more people become more familiar with the project

  • we use a simple namespace for branch names. It is not stricly enforced, but it is a good idea to follow it:

    • bug/fix-<numver>>: fix bug <numver>

    • wip/<branch>: Work In Progress, will not be tested by Jenkins

    • maint/<branch>: maintenance-related branches (release, changelog update, etc…)

    • ref/<branch>: refactoring branch (no new feature)

    • enh/<branch>: enhancement, new feature

    • maintenance/<branch>: maintenance branches (where code lives after a major release, e.g. maintenance/0.5.x)