9.1 KiB
Contributing to repo2docker development
This document covers:
- Process for making a code contribution
- Setting up for Local Development
- Running Tests
- Updating and Freezing BuildPack Dependencies
- Updating the change log
- Creating a Release
Process for making a code contribution
This outlines the process for getting changes to the code of repo2docker merged. This serves as information on when a PR is "done".
Contributions should follow these guidelines:
- all changes by pull request (PR);
- please prefix the title of your pull request with
[MRG]
if the contribution is complete and should be subjected to a detailed review; - create a PR as early as possible, marking it with
[WIP]
while you work on it (good to avoid duplicated work, get broad review of functionality or API, or seek collaborators); - a PR solves one problem (do not mix problems together in one PR) with the minimal set of changes;
- describe why you are proposing the changes you are proposing;
- try to not rush changes (the definition of rush depends on how big your changes are);
- someone else has to merge your PR;
- new code needs to come with a test;
- apply PEP8 as much as possible, but not too much;
- no merging if travis is red;
- do use merge commits instead of merge-by-squashing/-rebasing. This makes it
easier to find all changes since the last deployment
git log --merges --pretty=format:"%h %<(10,trunc)%an %<(15)%ar %s" <deployed-revision>..
- when you merge do deploy to mybinder.org
These are not hard rules to be enforced by 🚓 but instead guidelines.
Setting up for Local Development
To develop & test repo2docker locally, you need:
- Familiarity with using a command line terminal
- A computer running macOS / Linux
- Some knowledge of git
- At least python 3.6
- Your favorite text editor
- A recent version of Docker Community Edition
Clone the repository
First, you need to get a copy of the repo2docker git repository on your local disk.
git clone https://github.com/jupyter/repo2docker
This will clone repo2docker into a directory called repo2docker
. You can
make that your current directory with cd repo2docker
.
Set up a local virtual environment
After cloning the repository (or your fork of the repository), you should set up an
isolated environment to install libraries required for running / developing
repo2docker. There are many ways to do this, and a virtual environment
is
one of them.
python3 -m venv .
source bin/activate
pip3 install -e .
pip3 install -r dev-requirements.txt
pip3 install -r docs/doc-requirements.txt
This should install all the libraries required for testing & running repo2docker!
Verify that docker is installed and running
If you do not already have Docker, you should be able to download and install it for your operating system using the links from the official website. After you have installed it, you can verify that it is working by running the following commands:
docker version
It should output something like:
Client:
Version: 17.09.0-ce
API version: 1.32
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:42:45 2017
OS/Arch: linux/amd64
Server:
Version: 17.09.0-ce
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: afdb6d4
Built: Tue Sep 26 22:41:24 2017
OS/Arch: linux/amd64
Experimental: false
Then you are good to go!
Running tests
We have a lot of tests for various cases supported by repo2docker in the tests/
subdirectory. If you fix a bug or add new functionality consider adding a new
test to prevent the bug from coming back. These use
py.test.
You can run all the tests with:
py.test -s tests/*
If you want to run a specific test, you can do so with:
py.test -s tests/<path-to-test>
Update and Freeze BuildPack Dependencies
Updating libraries installed for all repositories
For both the conda
and virtualenv
(pip
) base environments in the Conda BuildPack and Python BuildPack,
we install specific pinned versions of all dependencies. We explicitly list the dependencies
we want, then freeze them at commit time to explicitly list all the
transitive dependencies at current versions. This way, we know that
all dependencies will have the exact same version installed at all times.
To update one of the dependencies shared across all repo2docker
builds, you
must follow these steps (with more detailed information in the sections below):
- Make sure you have Docker running on your computer
- Bump the version numbers of the dependencies you want to update in the
conda
environment (link) - Make a pull request with your changes (link)
See the subsections below for more detailed instructions.
Conda dependencies
-
There are two files related to conda dependencies. Edit as needed.
-
repo2docker/buildpacks/conda/environment.yml
Contains list of packages to install in Python3 conda environments, which are the default. This is where all Notebook versions & notebook extensions (such as JupyterLab / nteract) go.
-
repo2docker/buildpacks/conda/environment.py-2.7.yml
Contains list of packages to install in Python2 conda environments, which can be specifically requested by users. This only needs
IPyKernel
and kernel related libraries. Notebook / Notebook Extension need not be installed here.
-
-
Once you edit either of these files to add a new package / bump version on an existing package, you should then run:
cd ./repo2docker/buildpacks/conda/ python freeze.py
This script will resolve dependencies and write them to the respective
.frozen.yml
files. You will needdocker
installed to run this script. -
After the freeze script finishes, a number of files will have been created. Commit the following subset of files to git:
repo2docker/buildpacks/conda/environment.yml repo2docker/buildpacks/conda/environment.frozen.yml repo2docker/buildpacks/conda/environment.py-2.7.yml repo2docker/buildpacks/conda/environment.py-2.7.frozen.yml repo2docker/buildpacks/conda/environment.py-3.5.frozen.yml repo2docker/buildpacks/conda/environment.py-3.6.frozen.yml
-
Make a pull request; see details below.
-
Once the pull request is approved (but not yet merged), Update the change log (details below) and commit the change log, then update the pull request.
Change log
To add your change to the change log, find the relevant Feature/Bug fix/API change section for the next release near the top of the file; then add one or two sentences as a new bullet point about your changes. Include the pull request or issue number between square brackets at the end.
Some details:
-
versioning follows the x.y.z, major.minor.bugfix numbering
-
bug fixes go into the next bugfix release. If there isn't any, you can create a new section (see point below). Don't worry if you're not sure about that, and think it should go into a next major or minor release: an admin will let you know, or move the change later to the appropriate section
-
API changes should preferably go into the next major release, unless they are backward compatible (for example, a deprecated function keyword): then they can go into the next minor release. For release with major release 0, non-backward compatible breaking changes are also fine for the next minor release.
-
new features should go into the next minor release.
-
if there is no section for the appropriate release, you can add one:
follow the versioning scheme, by simply increasing the relevant number for one of the major /minor/bugfix numbers, appropriate for your change (see the above bullet points); add the release section. Then add three subsections: new features, api changes, and bug fixes. Leave out the sections that are not appropriate for the newlye added release section.
Release candidate versions in the change log are only temporary, and should be superseded by either a next release candidate, or the final release for that version (bugfix version 0).
Make a Pull Request
Once you've made the commit, please make a Pull Request to the jupyterhub/repo2docker
repository, with a description of what versions were bumped / what new packages were
added and why. If you fix a bug or add new functionality consider adding a new
test to prevent the bug from coming back/the feature breaking in the future.
Creating a Release
We try to make a release of repo2docker every few months if possible.
We follow semantic versioning.
Check hat the Change log is ready and then tag a new release on GitHub.
When the travis run completes check that the new release is available on PyPI.