Hacking on Dennis¶
This covers setting up Dennis to hack on. If you’re interested in using Dennis, but not hacking on it, then this probably isn’t going to be interesting to you.
Install Dennis and dependencies for development¶
Clone the repository from https://github.com/mozilla/dennis/
Create a virtual environment
Install dev requirements:
pip install -r requirements-dev.txt
This should get you up and running.
Helping out¶
The non-exhaustive list of things to do are in the issue tracker.
If you want to write some code or fix a bug or add some docs or in some way contribute to Dennis, please do so using the following process:
Tell me what you’re planning to do before you do it. Preferably in a comment in the issue tracker on a relevant issue. If not as a comment, then email me.
After I’ve been informed and given approval, continue!
Create a new branch for your changes.
Make your changes!
Update documentation or write new documentation for the changes you’ve made.
Update the tests or write new tests for the changes you’ve made.
Submit a patch.
To make it easier for me to maintain Dennis, all changes should either:
be submitted as a pull request in Github, or
emailed to me as an appropriately formatted patch
If you don’t know how to do either, then maybe you can find someone to help you out.
That’s it!
Anyone who contributes code, tests or docs (in other words, has a git commit with their name on it) get added to the CONTRIBUTORS file. Yay!
Tests¶
Tests are in tests/
. We use pytest as the test
runner.
To run the tests, do:
$ pytest
Please write tests for changes you make.
Documentation¶
Documentation is in docs/
. We use Sphinx as the documentation generator.
To build the docs, do:
$ cd docs/
$ make html
Please make changes to the documentation as required by the changes you make.
Release howto¶
Check out master tip.
Check to make sure
setup.py
andrequirements-dev.txt
files have correct versions of requirements.Update version number in
dennis/__init__.py
Set
__version__
to something like0.4
.Set
__releasedate__
to something like20120731
.
Update
CHANGELOG
. Usually, I do something like:git log --oneline v0.4..HEAD
replacing
v0.4
with the most recent tag. Then I copy and paste that, remove uninteresting lines and add a header.Verify correctness.
Run the tests with
tox
.Review the
README.rst
.Build the docs and review them.
Tag the release:
git tag -a v0.4
Copy the last section of the
CHANGELOG
into the tag commit message.Push everything:
git push --tags official master
Update PyPI:
rm -rf dist/* python setup.py sdist bdist_wheel twine upload dist/*
Announce the release.