Skip to content


Subversion checkout URL

You can clone with
Download ZIP
191 lines (125 sloc) 6.19 KB
Hacking on Substance D
Here are some guidelines about hacking on Substance D.
Using a Development Checkout
Below is a quick start on creating a development environment using a
Substance D checkout.
- Create a new directory somewhere and ``cd`` to it::
$ mkdir ~/hack-on-substanced
$ cd ~/hack-on-substanced
- Check out a read-only copy of the Substance D source::
$ git clone git://
(alternately, create a writeable fork on GitHub and check that out).
- Create a virtualenv in which to install Substance D::
$ virtualenv -p python2.7 --no-site-packages env
- Install ``setuptools-git`` into the virtualenv (for good measure, as we're
using git to do version control)::
$ env/bin/easy_install setuptools-git
- Install Substance D from the checkout into the virtualenv using ``
dev``. `` dev`` is an alias for " develop" which also
installs testing requirements such as nose and coverage. Running
`` dev`` *must* be done while the current working directory is the
``substanced`` checkout directory::
$ cd substanced
$ ../env/bin/python dev
- At that point, you should be able to create new Substance D projects by
using ``pcreate``::
$ cd ../env
$ bin/pcreate -s substanced myproj
- And install that project using `` develop`` into the
$ cd myproj
$ ../bin/python develop
- Run the resulting project via ``../bin/pserve development.ini``.
Adding Features
In order to add a feature to Substance D:
- The feature must be documented in both the API and narrative
documentation (in ``docs/``).
- The feature must work fully on the following CPython versions: 2.6, 2.7,
3.2, and 3.3 on both UNIX and Windows.
- The feature must work on the latest version of PyPy.
- The feature must not add unnecessary dependencies (where
"unnecessary" is of course subjective, but new dependencies should
be discussed).
The above requirements are relaxed for scaffolding dependencies. If a
scaffold has an install-time dependency on something that doesn't work on a
particular platform, that caveat should be spelled out clearly in *its*
documentation (within its ``docs/`` directory).
Coding Style
- PEP8 compliance. Whitespace rules are relaxed: not necessary to put
2 newlines between classes. But 80-column lines, in particular, are
mandatory. See for more
- Please do not remove trailing whitespace. Configure your editor to reduce
diff noise. See for more.
Running Substance D Tests
To run the full test suite (your system will need Python 2.6, 2.7, 3.2, and
3.3 to be installed):
- Install "tox" (``easy_install tox``).
- Run ``tox`` from within the top-level ``substanced`` directory.
To run all tests for a single version of Python:
- Run `` dev`` (this will install ``coverage`` and ``nose``).
- Run `` nosetests``.
To run coverage tests for a single version of Python:
- Run `` dev`` (this will install ``coverage`` and ``nose``).
- Run `` nosetests --with-coverage``.
- To run individual tests (i.e. during development) you can use a regular
expression with the ``-t`` parameter courtesy of the `nose-selecttests
<>`_ plugin that's been
installed (along with nose itself) via ``python dev``. The
easiest usage is to simply provide the verbatim name of the test you're
working on.
Internalization (adding/updating languages)
The Transifex project should be used for translations:
Before you can do anything related to translations, there is small setup:
- Run ``bin/python i18n``
To update Transifex with new translations:
- Run ``python extract_messages`` to populate `substanced.pot`.
- Run ``python update_catalog`` to update translation strings in
existing .po files.
- Run ``tx push -t -s`` to push translation files to Transifex to be
- Notify translators through Transifex.
To fetch translated files from Transifex:
- Run ``tx pull`` to update .po files with translations.
- Run ``python compile_catalog`` to update .mo files.
- Run `git commit -m "Update catalog" substanced/locales` to commit changes
(don't forget to submit changes upstream).
To add a new language:
- Run ``python init_catalog -l de``
Test Coverage
- The codebase *must* have 100% test statement coverage after each commit.
You can test coverage via ``tox -e coverage``, or alternately by installing
``nose`` and ``coverage`` into your virtualenv (easiest via ``
dev``), and running `` nosetests --with-coverage``.
Documentation Coverage and Building HTML Documentation
If you fix a bug, and the bug requires an API or behavior modification, all
documentation in this package which references that API or behavior must
change to reflect the bug fix, ideally in the same commit that fixes the bug
or adds the feature.
To build and review docs (where ``$yourvenv`` refers to the virtualenv you're
using to develop substanced):
1. Run ``$yourvenv/bin/python dev docs``. This will cause Sphinx
and all development requirements to be installed in your virtualenv.
2. cd to the ``docs`` directory within your substanced checkout and execute
``make clean html SPHINXBUILD=$yourvenv/bin/sphinx-build``. The
``SPHINXBUILD=...`` hair is there in order to tell it to use the
virtualenv Python, which will have both Sphinx and SubstanceD (for API
documentation generation) installed.
3. Open the ``docs/_build/html/index.html`` file to see the resulting HTML
Change Log
- Feature additions and bugfixes must be added to the ``CHANGES.txt``
file in the prevailing style. Changelog entries should be long and
descriptive, not cryptic. Other developers should be able to know
what your changelog entry means.
Jump to Line
Something went wrong with that request. Please try again.