You're reading the documentation for a development version. For the latest released version, please have a look at v0.1.1.

Contributing¶

First of all, thank you so much for contributing! 🎉 💯

This document contains guidelines on how to most effectively contribute within this repository.

If you are stuck, please feel free to ask any questions or ask for help.

Code of conduct¶

This project is governed by our code of conduct. By participating, you are expected to uphold this code. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to community leaders responsible for enforcement. Please open a new security advisory notice (using defaults or “n/a” where unable to fill in the form) to privately notify us of any incidents of this nature.

Development¶

This project leverages development environments managed by Python Poetry. We leverage interactions with the Docker through Python to achieve reproducible results through containers. We use pytest for testing and GitHub actions for automated tests.

Development setup¶

Perform the following steps to setup a Python development environment.

Install Python (we recommend using pyenv or similar)
Install Poetry
Install Poetry Environment: poetry install

Linting¶

Work added to this project is automatically checked using pre-commit via GitHub Actions. Pre-commit can work alongside your local git with git-hooks

After installing pre-commit within your development environment, the following command also can perform the same checks within your local development environment:

% pre-commit run --all-files

We use these same checks within our automated tests which are managed by GitHub Actions workflows. These automated tests generally must pass in order to merge work into this repository.

Testing¶

Work added to this project is automatically tested using pytest via GitHub Actions. Pytest is installed through the Poetry environment for this project. We recommend testing your work before opening pull requests with proposed changes.

You can run pytest on your work using the following example:

% poetry run pytest

Making changes to this repository¶

We welcome anyone to use GitHub issues (requires a GitHub login) or create pull requests (to directly make changes within this repository) to modify content found within this repository.

Specifically, there are several ways to suggest or make changes to this repository:

Open a GitHub issue: https://github.com/WayScience/coSMicQC/issues
Create a pull request from a forked branch of the repository

Creating a pull request¶

Pull requests¶

After you’ve decided to contribute code and have written it up, please file a pull request. We specifically follow a forked pull request model. Please create a fork of this repository, clone the fork, and then create a new, feature-specific branch. Once you make the necessary changes on this branch, you should file a pull request to incorporate your changes into this (fork upstream) repository.

The content and description of your pull request are directly related to the speed at which we are able to review, approve, and merge your contribution. To ensure an efficient review process please perform the following steps:

Follow all instructions in the pull request template
Triple check that your pull request is adding one specific feature or additional group of content. Small, bite-sized pull requests move so much faster than large pull requests.
After submitting your pull request, ensure that your contribution passes all status checks (e.g. passes all tests)

Pull request review and approval is required by at least one project maintainer to merge. We will do our best to review the code addition in a timely fashion. Ensuring that you follow all steps above will increase our speed and ability to review. We will check for accuracy, style, code coverage, and scope.

Versioning¶

We use poetry-dynamic-versioning to help version this software through PEP 440 standards. Configuration for versioning is found within the pyproject.toml file. All builds for packages include dynamic version data to help label distinct versions of the software. poetry-dynamic-versioning uses git tags to help distinguish version data. We also use the __init__.py file as a place to persist the version data for occaissions where the git history is unavailable or unwanted.

The following command is used to add poetry-dynamic-versioning to Poetry for use with this project: poetry self add "poetry-dynamic-versioning[plugin]". Versioning for the project is intended to align with GitHub Releases which provide git tag capabilities.

Releases¶

We publish source code by using GitHub Releases available here. We publish a related Python package through the Python Packaging Index (PyPI) available here.

Release Publishing Process¶

Several manual and automated steps are involved with publishing coSMicQC releases. See below for an overview of how this works.

Notes about semantic version (semver) specifications: coSMicQC version specifications are controlled through poetry-dynamic-versioning which leverages dunamai to create version data based on git tags and commits. coSMicQC release git tags are automatically applied through GitHub Releases and related inferred changes from release-drafter.

Open a pull request and use a repository label for release-<semver release type> to label the pull request for visibility with release-drafter (for example, see coSMicQC#24 as a reference of a semver patch update).
On merging the pull request for the release, a GitHub Actions workflow defined in draft-release.yml leveraging release-drafter will draft a release for maintainers.
The draft GitHub release will include a version tag based on the GitHub PR label applied and release-drafter.
Make modifications as necessary to the draft GitHub release, then publish the release (the draft release does not normally need additional modifications).
On publishing the release, another GitHub Actions workflow defined in publish-pypi.yml will run to build and deploy the Python package to PyPI (utilizing the earlier modified pyproject.toml semantic version reference for labeling the release).

Documentation¶

Documentation for this project is published using Sphinx with markdown and Jupyter notebook file compatibility provided by myst-parser and myst-nb to create a “documentation website” (also known as “docsite”). The docsite is hosted through GitHub Pages and deployed through automated GitHub Actions jobs which trigger on pushes to the main branch or the publishing of a new release on GitHub. Documentation is versioned as outlined earlier sections covering versioning details to help ensure users are able to understand each release independently of one another.

It can sometimes be useful to test documentation builds locally before proposing changes within a pull request. See below for some examples of how to build documentation locally.

# build single-version sphinx documentation
# (useful for troubleshooting potential issues)
poetry run sphinx-build docs/src docs/build

# build multi-version sphinx documentation
# (used in production)
poetry run sphinx-multiversion docs/src docs/build

After the docs build, navigate the docs/build folder and open the HTML files with your browser. Opening the index.html file which may be found in the base of docs/build or docs/build/<version> will simulate the docsite experience through GitHub Pages.