How To Contribute¶
First off, thank you for considering contributing to forge
!
This document intends to make contribution more accessible by codifying tribal knowledge and expectations. Don’t be afraid to open half-finished PRs, and ask questions if something is unclear!
Workflow¶
- No contribution is too small! Please submit as many fixes for typos and grammar bloopers as you can!
- Try to limit each pull request to one change only.
- Always add tests and docs for your code. This is a hard rule; patches with missing tests or documentation can’t be merged.
- Make sure your changes pass our CI. You won’t get any feedback until it’s green unless you ask for it.
- Once you’ve addressed review feedback, make sure to bump the pull request with a short note, so we know you’re done.
Code¶
Obey PEP 8 and PEP 257. We use the
"""
-on-separate-lines style for docstrings:def func(x): """ Do something. :param str x: A very important parameter. :rtype: str """
If you add or change public APIs, tag the docstring using
.. versionadded:: 16.0.0 WHAT
or.. versionchanged:: 16.2.0 WHAT
.Prefer double quotes (
"
) over single quotes ('
) unless the string contains double quotes itself.
Tests¶
Write your asserts as
actual == expected
to line them up nicely:x = f() assert x.some_attribute == 42 assert x._a_private_attribute == 'foo'
To run the test suite, all you need is a recent tox. It will ensure the test suite runs with all dependencies against all Python versions just as it will on Travis CI.
Write good test docstrings.
Documentation¶
Use semantic newlines in reStructuredText files (files ending in
.rst
):This is a sentence. This is another sentence.
If you start a new section, add two blank lines before and one blank line after the header, except if two headers follow immediately after each other:
Last line of previous section. Header of New Top Section ========================= Header of New Section --------------------- First line of new section.
If you add a new feature, demonstrate its awesomeness on the basic page!
Release¶
The recipe for releasing new software looks like this:
- Add functionality / docstrings as appropriate
- Add tests / docstrings as necessary
- Update
documentation
andchangelog
- Tag release in
setup.cfg
(and update badge in theREADME
. - Merge branch into master
- Add a git tag for the release
- Build a release using
python setup.py bdist_wheel
and publish to PYPI as described in Packaging Python Projects
Local Development Environment¶
You can (and should) run our test suite using tox.
However, you’ll probably want a more traditional environment as well.
We highly recommend to develop using the latest Python 3 release because forge
tries to take advantage of modern features whenever possible.
First create a virtual environment.
Next, get an up to date checkout of the forge
repository:
$ git checkout git@github.com:dfee/forge.git
Change into the newly created directory and after activating your virtual environment install an editable version of forge
along with its tests and docs requirements:
$ cd forge
$ pip install -e .[dev]
At this point,
$ python -m pytest
should work and pass, as should:
$ cd docs
$ make html
The built documentation can then be found in docs/_build/html/
.