Contributing to surmise

Contributions may be made via a GitHub pull request to

surmise uses the Gitflow model. Contributors should branch from, and make pull requests to, the develop branch. The main branch is used only for releases. Pull requests may be made from a fork, for those without repository write access.

Issues can be raised at

When a branch closes a related issue, the pull request message should include the phrase “Closes #N,” where N is the issue number. This will automatically close out the issues when they are pulled into the default branch (currently main).

Testing contributions

Code should pass flake8 tests, allowing for the exceptions given in the flake8 file in the project directory. Some rules of flake8 can be seen at https://www.flake8rules.com. To check if the code passes the flake8 tests, within the directory run:

flake8

As you develop your code, we ask developers to include tests specific to their code, and provide their own tests in the src\tests\ directory. To run the new tests, you can run the following:

pytest src/tests/your-test.py

When a pull request is done to include a new method, we ask developers to include their tests.

Documentation

Clear and complete documentation is essential in order for users to be able to find and understand the code.

Documentation for individual functions and classes – which includes at least a basic description, type, and meaning of all parameters, and returns values and usage examples – is put in docstrings. Those docstrings can be read within the interpreter, and are compiled into a reference guide in html and pdf format. If you want to contribute to the documentation of the architecture of surmise, you can write documentation in reStructuredText format, and edit in the \docs directory. If you run make html in the same directory, HTML pages can viewed. As you develop your code, we recommend writing docstrings in your classes and methods.

On any code that is not self-documenting, provide clear comments when some important thing must be communicated to the user. There is no general rule for the number of needed comments. Some examples of bad and good commenting habits are given below.

Lack of comments:

Bad Example:

def mySqrt(x):

    r = x
    precision = 10 ** (-10)

    while abs(x - r * r) > precision:
        r = (r + x / r) / 2

    return r

Good Example:

# square root of x with Newton-Raphson approximation
def mySqrt(x):

    r = x
    precision = 10 ** (-10)

    while abs(x - r * r) > precision:
        r = (r + x / r) / 2

    return r

Do not use excessive comments.

Bad Example:

# looping in range from 0 to 9 and printing the value to the console
for x in range(10):
  print(x)

Good Example:

# 0, 1 .. 9
for x in range(10):
  print(x)
Some general guidance on commenting code can be found at:

https://www.cs.utah.edu/~germain/PPS/Topics/commenting.html

and:

https://www.exascaleproject.org/wp-content/uploads/2021/01/Good-practices-for-research-software-documentation-first.pdf

Developer’s Certificate of Origin 1.1

surmise is distributed under an MIT license (see LICENSE). The act of submitting a pull request (with or without an explicit Signed-off-by tag) will be understood as an affirmation of the following:

By making a contribution to this project, I certify that:

  1. The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or

  2. The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or

  3. The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it.

  4. I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.

tox Developer Environments

The tool tox has been integrated in the repository. Developers can optionally use this tool to execute different tasks as well as to setup and manage Python virtual environments dedicated to different development purposes based on the configuration managed by surmise maintainers. Developers that would like to use our tox environments should learn at the very least the difference between calling tox -r -e <task> and tox -e <task>.

To use tox, developers must first install it. The following procedure installs tox in a dedicated, minimal virtual environment and is based on a webinar presented by Oliver Bestwalter.

Execute the following with changes made to adapt to the developer’s needs

$ /path/to/target/python --version
$ /path/to/target/python -m venv $HOME/.toxbase
$ $HOME/.toxbase/bin/pip list
$ $HOME/.toxbase/bin/python -m pip install --upgrade pip
$ $HOME/.toxbase/bin/python -m pip install --upgrade setuptools
$ $HOME/.toxbase/bin/python -m pip install tox
$ $HOME/.toxbase/bin/tox --version
$ $HOME/.toxbase/bin/pip list

Alter PATH so that tox is immediately available. To follow Oliver’s suggestion, execute some variation of

$ mkdir $HOME/local/bin
$ ln -s $HOME/.toxbase/bin/tox $HOME/local/bin/tox
$ vi $HOME/.bash_profile (add $HOME/local/bin to PATH)
$ . $HOME/.bash_profile
$ which tox
$ tox --version

By default, tox will not carry out any work if only tox or tox -r is executed. The following tasks can be run from the root of any surmise clone.

  • tox -e coverage

    • Run the full surmise test suite with coverage-by-line enabled and using the current state of the code in the local clone

    • The coverage-by-line results are stored for generating a coverage report. See tox -e report below.

  • tox -e nocoverage

    • Run the full surmise test suite with surmise installed as a Python package

  • tox -e emu_cal

    • Run the standard emulator/calibrator tests of code integration using the current state of the code in the local clone

  • tox -e new_emu

    • Run the new emulator tests using the current state of the code in the local clone

  • tox -e new_cal

    • Run the new calibrator tests using the current state of the code in the local clone

  • tox -e report

    • Generate an HTML-format coverage-by-line report for inspection. This assumes that coverage was already called or is called at the same time.

  • tox -e check

    • Run checks on the code and report any possible issues. Note that this task does not alter the contents of any files.

  • tox -e html

    • Generate in docs/build_html the package’s sphinx-based documentation in HTML format

  • tox -e pdf

    • Generate in docs/build_pdf the package’s sphinx-based documentation as a PDF file

  • tox -e book

    • Generate from scratch in book/_build the package’s examples Jupyter book

    • Using this task repeatedly to interactively develop individual notebooks can be inefficient. A workaround is to run tox -r -e book once at the start of development, load the book venv, render the notebook at each step using a simpler version of the build command for this task (see tox.ini), and rerun tox -r -e book once finished.

Developers can also run multiple tasks at once by executing, for example,

tox -e report,coverage

Note that developers can directly use the virtual environments created by tox by activating them as usual. For example, to use a virtual environment with surmise installed in editable or developer mode (i.e., using pip install -e surmise), run tox -e coverage if you have not already and execute

. /path/to/surmise/.tox/coverage/bin/activate