About
- Purpose: Implement the novel method developed by the aforementioned authors
- GNU General Public License
- First released 2014
- Python 2.7, upgraded to 3.6
Overview
- About/Motivation
- Git-Based Workflow
- Contribution, Communication
- Testing, Coverage, Versioning
- Pull Requests
- Continuous Integration
- Documentation
- Publishing, Releases, Licenses
About/Motivation
- Reproduce results in research
- Demonstrate utility of approach
- Upgrading
- Python 2.7 will be deprecated by 2020
- New features in ConsistentBayes repo
- Desire to unify frameworks
- Repository needed some love
Git-Based Workflow
- Fork project
- Clone your fork
- Create branch for new feature(s)
- Checkout branch, make changes
- Commit files with informative messages
- Push branch back to your remote fork
- Use GitHub to start Pull-Request
- Communicate (if needed) until PR is merged (or not)
Contribution, Communication
- Make sure your contribution would be welcome
- Consider starting a new “Issue” on GitHub to ask
- Read the existing documentation (
README, CONTRIBUTE, etc)
- Ensure you understand the necessary requirements
Unit-Testing, Coverage, Versioning
nose is a Python package/framework for unit testing
codecov works in conjuction
- checks which lines of code your test called
setup.py contains versioning information
- Major/Minor releases depend on extent of changes
- The third number in
v1.2.3 is for incremental changes, such as bug-fixes, typos, patches, etc.
Nosetests
- One-to-one file structure
- one test (class) for each sub-module method
- multiple “tests” within each
- Class consists of several methods
setup and teardown required
- test for each function within module
- Each test should anticipate mixtures of arguments that could be passed to each function
Nosetest Example
from unnecessary_math import multiply
def test_numbers_3_4():
assert multiply(3,4) == 12
def test_strings_a_3():
assert multiply('a',3) == 'aaa'
nosetests -v test_um_nose.py
Source
Pull Requests

Continuous Integration
- If enabled, remote server then
- Carries out instructions on UNIX image
- Communicates with GitHub about test status
- Ensures consistency of installation
- Someone has to pay for the computer
- Can run local versions
- Most “real” projects include CI
Continuous Integration
- Travis runs when you submit a PR to check that everything works
- GitHub checks for ability to merge automatically
- Passing does not ensure a PR is merged
- Ultimiately up to the admininstrators of the repo
- Helpful for contributors to debug before admins take a look
- If checks do not pass, adding commits to your branch will automatically trigger new CI builds, updates to the PR
Documentation
BET is auto-documented using a tool called Sphinx
r"""
This is a description of the method.
All sorts of formatting options are understood by Sphinx.
(kind of something to learn on its own, but usually you
can make sense of syntax by looking at existing ones)
"""
- Comments that are formatted inside blocks are converted into web-page documentation
- Updating docs through command-line
- GitHub pages used to host the resulting output
Licensing
Many open-source models to choose from.
Publishing
- GitHub (Microsoft)
- GitLab (VC-funded, Private)
- Bitbucket (Atlassian)
- Anaconda (Community)
- PyPi (Community)
- (Suggested) Website
What I Did
- Most of what was written about here
- Intent was to upgrade to Python 3.6
- Used a tool called
2to3
- Takes care of most major changes
- Two weeks fixing tests
- Once tests fixed, worked on upgrading dependencies
- Updated examples, copyrights, comments, styling
- Preparing for release
2.1.0, PR ready to be merged
- Version
3.0.0 will incorporate cbayes features