Know What You Want to Write Code to Do¶
Do you want to write code to resolve an open issue (bug)? Which one?
Do you want to implement a BigchainDB Enhancement Proposal (BEP)? Which one?
You should know why you want to write code before you go any farther.
Refresh Yourself about the C4 Process¶
C4 is the Collective Code Construction Contract. It’s quite short: re-reading it will only take a few minutes.
Set Up Your Local Machine. Here’s How.¶
- Make sure you have Git installed.
- Get a text editor. Internally, we like:
- Visual Studio Code
- GNU Emacs (Trent is crazy)
- GNU nano (Troy has lost his mind)
- If you plan to do Python coding, get the latest Python, and
get the latest
Don’t use apt or apt-get to get the latest
pip. It won’t work properly. Use
from the pip website.
Use the latest
pipto get the latest
$ pip install virtualenv
Create a Python Virttual Environment (virtualenv) for doing BigchainDB Server development. There are many ways to do that. Google around and pick one. An old-fashioned but fine way is:
$ virtualenv -p $(which python3.6) NEW_ENV_NAME $ . NEW_ENV_NAME/bin/activate
Be sure to use Python 3.6.x as the Python version for your virtualenv. The virtualenv creation process will actually get the latest
setuptoolsand put them inside the new virtualenv.
Before You Start Writing Code¶
Read BEP-24 so you know what to do to ensure that your changes (i.e. your future pull request) can be merged. It’s easy and will save you some hassle later on.
Start Writing Code¶
Use the Git Fork and Pull Request Workflow. Tip: You could print that page for reference.
Make sure pre-commit actually checks commits. Do:
$ pip install pre-commit # might not do anything if it is already installed, which is okay $ pre-commit install
That will load the pre-commit settings in the file
.pre-commit-config.yaml. Now every time you do
git commit <stuff>, pre-commit
will run all those checks.
To install BigchainDB Server from the local code, and to keep it up to date with the latest code in there, use:
$ pip install -e .[dev]
-e tells it to use the latest code. The
. means use the current directory, which should be the one containing
[dev] tells it to install some extra Python packages. Which ones? Open
setup.py and look for
dev in the
Remember to Write Tests¶
We like to test everything, if possible. Unit tests and also integration tests. We use the pytest framework to write Python tests. Read all about it.
Most tests are in the
tests/ folder. Take a look around.
Running a Local Node/Network for Dev and Test¶
This is tricky and personal. Different people do it different ways. We documented some of those on separate pages:
Create the PR on GitHub¶
Git push your branch to GitHub so as to create a pull request against the branch where the code you want to change lives.
Travis and Codecov will run and might complain. Look into the complaints and fix them before merging. Travis gets its configuration and setup from the files:
- Some environment variables, if they are used. See https://docs.travis-ci.com/user/environment-variables/
tox.ini- What is tox? See tox.readthedocs.io
.ci/(as in Travis CI = Continuous Integration)
Read about the Travis CI build lifecycle to understand when those scripts run and what they do. You can have even more scripts!
Ideally, we like your PR and merge it right away. We don’t want to keep you waiting.
If we want to make changes, we’ll do them in a follow-up PR.