Contributing¶

Acquiring the Codebase¶
In order to contribute new code or documentation changes, you will need a local copy of the source code which is located on the NuCypher GitHub.
Note
NuCypher uses git
for version control. Be sure you have it installed.
Here is the recommended procedure for acquiring the code in preparation for contributing proposed changes:
Use GitHub to fork the
nucypher/nucypher
repositoryClone your fork’s repository to your local machine
$ git clone https://github.com/<YOUR-GITHUB-USERNAME>/nucypher.git
Change directory to
nucypher
$ cd nucypher
Add
nucypher/nucypher
as an upstream remote
$ git remote add upstream https://github.com/nucypher/nucypher.git
Update your remote tracking branches
$ git remote update
Install the project dependencies: see the Developer Installation Guide
Running the Tests¶
Note
A development installation including the solidity compiler is required to run the tests
There are several test implementations in nucypher
, however, the vast majority
of test are written for execution with pytest
.
For more details see the Pytest Documentation.
To run the tests:
(nucypher)$ pytest -s
Optionally, to run the full, slow, verbose test suite run:
(nucypher)$ pytest
Setup Commit & Push Hooks¶
Pre-commit and pre-push are used for quality control to identify and prevent the inclusion of problematic code changes. They may prevent a commit that will fail if passed along to CI servers or make small formatting changes directly to source code files.
If it’s not already installed in your virtual environment, install pre-commit:
(nucypher)$ pip install pre-commit
To enable pre-commit checks:
(nucypher)$ pre-commit install
To enable pre-push checks:
(nucypher)$ pre-commit install -t pre-push
For convenience, here is a one-liner to enable both:
(nucypher)$ pre-commit install && pre-commit install -t pre-push
Making a Commit¶
NuCypher takes pride in its commit history.
When making a commit that you intend to contribute, keep your commit descriptive and succinct. Commit messages are best written in full sentences that make an attempt to accurately describe what effect the changeset represents in the simplest form. (It takes practice!)
Imagine you are the one reviewing the code, commit-by-commit as a means of understanding the thinking behind the PRs history. Does your commit history tell an honest and accurate story?
We understand that different code authors have different development preferences, and others are first-time contributors to open source, so feel free to join our Discord and let us know how we can best support the submission of your proposed changes.
Opening a Pull Request¶
When considering including commits as part of a pull request into nucypher/nucypher
,
we highly recommend opening the pull request early, before it is finished with
the mark “[WIP]” prepended to the title. We understand PRs marked “WIP” to be subject to change,
history rewrites, and CI failures. Generally we will not review a WIP PR until the “[WIP]” marker
has been removed from the PR title, however, this does give other contributors an opportunity
to provide early feedback and assists in facilitating an iterative contribution process.
Pull Request Conflicts¶
As an effort to preserve authorship and a cohesive commit history, we prefer if proposed contributions
are rebased over main
(or appropriate branch) when a merge conflict arises,
instead of making a merge commit back into the contributors fork.
Generally speaking the preferred process of doing so is with an interactive rebase:
Important
Be certain you do not have uncommitted changes before continuing.
Update your remote tracking branches
$ git remote update
... (some upstream changes are reported)
Initiate an interactive rebase over
nucypher/nucypher@main
Note
This example specifies the remote name upstream
for the NuCypher organizational repository as
used in the Acquiring the Codebase section.
$ git rebase -i upstream/main
... (edit & save rebase TODO list)
Resolve Conflicts
$ git status
... (resolve local conflict)
$ git add path/to/resolved/conflict/file.py
$ git rebase --continue
... ( repeat as needed )
Push Rebased History
After resolving all conflicts, you will need to force push to your fork’s repository, since the commits are rewritten.
Warning
Force pushing will override any changes on the remote you push to, proceed with caution.
$ git push origin my-branch -f
Building Documentation¶
Note
sphinx
and sphinx_rtd_theme
are non-standard dependencies that can be installed
by running pip install -e .[docs]
from the project directory.
Documentation for nucypher
is hosted on Read The Docs, and is automatically built without intervention by following the release procedure.
However, you may want to build the documentation html locally for development.
To build the project dependencies locally on Linux:
(nucypher)$ make docs
or on MacOS:
(nucypher)$ make mac-docs
If the build is successful, the resulting local documentation homepage, nucypher/docs/build/html/index.html
, will
be automatically opened in the web browser.
Note
If you would rather not have the homepage automatically opened, then run make build-docs
instead.
Building Docker¶
Docker builds are automated as part of the publication workflow on circleCI and pushed to docker cloud. However you may want to build a local version of docker for development.
We provide both a docker-compose.yml
and a Dockerfile
which can be used as follows:
Docker Compose:
(nucypher)$ docker-compose -f deploy/docker/docker-compose.yml build .
Issuing a New Release¶
Note
This process uses towncrier
and bumpversion
, which can be installed by running pip install -e .[deploy]
or pip install towncrier bumpversion
.
Also note that it requires you have git commit signing properly configured.
Important
Ensure your local tree is based on main
and has no uncommitted changes.
1. Decide what part of the version to bump.
The version string follows the format {major}.{minor}.{patch}-{stage}.{devnum}
,
so the options are major
, minor
, patch
, stage
, or devnum
.
We usually issue new releases increasing the devnum
version.
2. Use the make release
script, specifying the version increment with the bump
parameter.
For example, for a new devnum
release, we would do:
(nucypher)$ make release bump=devnum
3. The previous step triggers the publication webhooks on CircleCI. Monitor the triggered deployment build for manual approval.