CONTRIBUTING.rst
.. _howto_contribute:
Developing open source software as part of a community is fun, and often quite educational!
We coordinate our work using GitHub, where you can find lists of open issues <https://github.com/scikit-image/scikit-image/issues?q=is%3Aopen>__
and new feature requests <https://github.com/scikit-image/scikit-image/labels/%3Apray%3A%20Feature%20request>__.
To follow along with discussions, or to get in touch with the
developer team, please join us on the scikit-image developer forum <https://discuss.scientific-python.org/c/contributor/skimage>_ and
the Zulip chat <https://skimage.zulipchat.com/>_.
Please post questions to these public forums (rather than contacting developers directly); that way, everyone can benefit from the answers, and developers can answer according to their availability. Don't feel shy, the team is very friendly!
.. contents:: :local:
The following is a brief overview about how changes to source code and documentation can be contributed to scikit-image.
If you are a first-time contributor:
Go to https://github.com/scikit-image/scikit-image <https://github.com/scikit-image/scikit-image>_ and click the
"fork" button to create your own copy of the project.
Set up GitHub SSH authentication <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>__.
Clone (download) the repository with the project source on your local computer::
git clone --origin upstream [email protected]:scikit-image/scikit-image
Change into the root directory of the cloned repository::
cd scikit-image
Add your fork as a
remote repository <https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes>__
that you will interact with.
Assuming a GitHub username of codemonkey::
git remote add codemonkey [email protected]:codemonkey/scikit-image git fetch codemonkey
You now have two remote repositories:
upstream, which refers to the scikit-image project repository, andcodemonkey, which refers to your personal fork.Next, :ref:set up your build environment <build-env-setup>.
Finally, we recommend that you use our pre-commit hook, which runs code
checkers and formatters each time you do a git commit::
pip install pre-commit pre-commit install
Develop your contribution:
Pull the latest changes from the project::
git switch main git fetch upstream main git merge upstream/main
Create a branch for the feature you want to work on. Use a sensible name, such as 'transform-speedups'::
git switch -c transform-speedups
Commit locally as you progress (with git add and git commit).
Please write good commit messages <https://vxlabs.com/software-development-handbook/#good-commit-messages>_.
To submit your contribution:
Push your changes back to your fork on GitHub:
::
git push codemonkey transform-speedups
A message will be displayed with a URL to open in your browser to create a pull request (PR). Open it and click the green button.
.. tip::
If you get stuck, reach out to us on
our Zulip chat <https://skimage.zulipchat.com/>__.
Review process:
Reviewers (the other developers and interested community members) will write inline and/or general comments on your pull request (PR) to help you improve its implementation, documentation, and style. Every single developer working on the project has their code reviewed, and we've come to see it as a friendly conversation from which we all learn and the overall code quality benefits. Therefore, please don't let the review discourage you from contributing: its only aim is to improve the quality of the project, not to criticize (we are, after all, very grateful for the time you're putting in!).
To update your pull request, make your changes on your local repository and commit. As soon as those changes are pushed up (to the same branch as before) the pull request will update automatically.
Continuous integration (CI) services are triggered after each pull request submission to build the package, run unit tests, and check the coding style and formatting of your branch. The tests must pass before your PR can be merged. If CI fails, you can find out why by clicking on the "failed" icon (red cross) and inspecting the build and test logs.
.. note:: PR labeling
CI will always fail on new PRs, until a maintainer adds a suitable category label.
A pull request must be approved by two core team members before merging.
.. _documenting-changes:
Document changes
If your change introduces a deprecation, add a reminder to TODO.txt
for the team to remove the deprecated functionality in the future.
scikit-image uses changelist <https://github.com/scientific-python/changelist>_
to generate a list of release notes automatically from pull requests. By
default, changelist will use the title of a pull request and its GitHub
labels to sort it into the appropriate section. However, for more complex
changes, we encourage you to describe them in more detail using the
release-note code block within the pull request description; e.g.::
```release-note
Remove the deprecated function `skimage.color.blue`. Blend
`skimage.color.cyan` and `skimage.color.magenta` instead.
```
You can refer to :doc:/release_notes/index for examples and to
changelist's documentation <https://github.com/scientific-python/changelist>_
for more details.
.. note::
To reviewers: if it is not obvious from the PR description, make sure that the reason and context for a change are described in the merge message.
upstream main and your feature branchIf GitHub indicates that the branch of your PR can no longer be merged automatically, merge the main branch into yours::
git fetch upstream main git merge upstream/main
If any conflicts occur, they need to be fixed before continuing <https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line>__.
We recommend <https://github.com/stefanv/git-tools?tab=readme-ov-file#conflict-diff-display>__ setting::
git config --global merge.conflictstyle zdiff3
to make conflict markers easier to read.
An alternative to merging is to rebase your branch—but we squash and merge all PRs anyway, so we don't mind merge commits.
test coverage_ below for more details).standard <https://numpydoc.readthedocs.io/en/latest/format.html#docstring-standard>_ as NumPy and SciPy.Gallery_ below for more details).developer forum <https://discuss.scientific-python.org/c/contributor/skimage>_ if
you get no response to your pull request.
Never merge your own pull request.Use the following import conventions::
import numpy as np import matplotlib.pyplot as plt import scipy as sp import skimage as ski
sp.ndimage.label(...) ski.measure.label(...)
Use numpy data types instead of strings (np.uint8 instead of
"uint8").
When documenting array parameters, use image : ndarray of shape (M, N)
and then refer to M and N in the docstring, if necessary.
Refer to array dimensions as (plane), row, column, not as x, y, z. See
:ref:Coordinate conventions <numpy-images-coordinate-conventions>
in the user guide for more information.
Functions should support all input image dtypes. Use utility functions such
as img_as_float to help convert to an appropriate type. The output
format can be whatever is most efficient. This allows us to string together
several functions into a pipeline, e.g.::
hough(canny(my_image))
Use relative module imports, i.e. from .._shared import xyz rather than
from skimage._shared import xyz.
For Cython functions:
with nogil:.Use Py_ssize_t as data type for all indexing, shape and size variables
in C/C++ and Cython code.
The test suite must pass before a pull request can be merged, and tests should be added to cover all modifications in behavior.
Tests are located in the tests/ directory.
We also test examples in docstrings of our package (located in src/).
For local development we use spin test which wraps the
pytest testing framework <https://docs.pytest.org/en/latest/>__.
Examples of running spin test:
.. code-block:: shell
# All tests
spin test
# Tests inside directory(s)
spin test -- tests/skimage/morphology
spin test -- src/skimage/morphology tests/skimage/morphology
# Tests matching an expression
spin test -- -k threshold
# Combine above with test path to reduce test collection time
spin test -- tests/skimage/filters -k threshold
# Specific test
spin test -- tests/skimage/morphology/test_gray.py::test_3d_fallback_black_tophat
.. tip::
Arguments specified after the ``--`` are forwarded as
`options to pytest <https://docs.pytest.org/en/stable/reference/reference.html#command-line-flags>`__.
Testing requirements are listed in requirements/test.txt.
Warnings during testing phase ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
By default, warnings raised by the test suite result in errors.
You can switch that behavior off by setting the environment variable
SKIMAGE_TEST_STRICT_WARNINGS to 0.
Tests for a module should ideally cover all code in that module, i.e., statement coverage should be at 100%.
To measure test coverage run::
$ spin test --coverage
This will run tests and print a report with one line for each file in skimage,
detailing the test coverage::
skimage/color/colorconv 77 77 100% skimage/filter/init 1 1 100% ...
To build the HTML documentation, run:
.. code:: sh
spin docs
Output is in scikit-image/doc/build/html/. Add the --clean
flag to build from scratch, deleting any cached output.
Gallery ^^^^^^^
The example gallery is built using
Sphinx-Gallery <https://sphinx-gallery.github.io>_.
Refer to their documentation for complete usage instructions, and also
to existing examples in doc/examples.
Gallery examples should have a maximum figure width of 8 inches.
You can also change a gallery entry's thumbnail <https://sphinx-gallery.github.io/stable/configuration.html#choosing-thumbnail>_.
Fixing Warnings ^^^^^^^^^^^^^^^
"citation not found: R###" There is probably an underscore after a reference in the first line of a docstring (e.g. [1]_). Use this method to find the source file: $ cd doc/build; grep -rin R####
"Duplicate citation R###, other instance in..."" There is probably a [2] without a [1] in one of the docstrings
Make sure to use pre-sphinxification paths to images (not the _images directory)
If the way a function is called has to be changed, a deprecation cycle must be followed to warn users.
A deprecation cycle is not necessary when:
A deprecation cycle is necessary when:
Typically, deprecation warnings are in place for two releases, before a change is made.
For example, consider the modification of a default value in a function signature. In version N, we have:
.. code-block:: python
def some_function(image, rescale=True):
"""Do something.
Parameters
----------
image : ndarray
Input image.
rescale : bool, optional
Rescale the image unless ``False`` is given.
Returns
-------
out : ndarray
The resulting image.
"""
out = do_something(image, rescale=rescale)
return out
In version N+1, we will change this to:
.. code-block:: python
def some_function(image, rescale=None):
"""Do something.
Parameters
----------
image : ndarray
Input image.
rescale : bool, optional
Rescale the image unless ``False`` is given.
.. warning:: The default value will change from ``True`` to
``False`` in skimage N+3.
Returns
-------
out : ndarray
The resulting image.
"""
if rescale is None:
warn('The default value of rescale will change '
'to `False` in version N+3.', stacklevel=2)
rescale = True
out = do_something(image, rescale=rescale)
return out
And, in version N+3:
.. code-block:: python
def some_function(image, rescale=False):
"""Do something.
Parameters
----------
image : ndarray
Input image.
rescale : bool, optional
Rescale the image if ``True`` is given.
Returns
-------
out : ndarray
The resulting image.
"""
out = do_something(image, rescale=rescale)
return out
Here is the process for a 3-release deprecation cycle:
None, and modify the
docstring to specify that the default is True.None, set it to True and warn that the
default will change to False in version N+3.doc/release/release_dev.rst, under deprecations, add "In
some_function, the rescale argument will default to False in N+3."TODO.txt, create an item in the section related to version
N+3 and write "change rescale default to False in some_function".Note that the 3-release deprecation cycle is not a strict rule and, in some cases, developers can agree on a different procedure.
Raising Warnings ^^^^^^^^^^^^^^^^
skimage raises FutureWarning\ s to highlight changes in its
API, e.g.:
.. code-block:: python
from warnings import warn
warn(
"Automatic detection of the color channel was deprecated in "
"v0.19, and channel_axis=None will be the new default in "
"v0.22. Set channel_axis=-1 explicitly to silence this "
"warning.",
FutureWarning,
stacklevel=2,
)
The stacklevel <https://docs.python.org/3/library/warnings.html#warnings.warn>_ is
a bit of a technicality, but ensures that the warning points to the
user-called function, and not to a utility function within.
In most cases, set the stacklevel to 2.
When warnings originate from helper routines internal to the
scikit-image library, set it to 3.
To test if your warning is being emitted correctly, try calling the function from an IPython console. It should point you to the console input itself instead of being emitted by files in the scikit-image library:
ipython:1: UserWarning: ...scikit-image/skimage/measure/_structural_similarity.py:155: UserWarning:Deprecating Keywords and Functions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
When removing keywords or entire functions, the
skimage._shared.utils.deprecate_parameter and
skimage._shared.utils.deprecate_func utility functions can be used
to perform the above procedure.
While code is hosted on GitHub <https://github.com/scikit-image/>,
example datasets are on GitLab <https://gitlab.com/scikit-image/data>.
These are fetched with pooch <https://github.com/fatiando/pooch>_
when accessing skimage.data.*.
New datasets are submitted on GitLab and, once merged, the data
registry skimage/data/_registry.py in the main GitHub repository
can be updated.
While not mandatory for most pull requests, we ask that performance-related PRs include a benchmark in order to clearly depict the use case that is being optimized for.
In this section we will review how to setup the benchmarks,
and three commands spin asv -- dev, spin asv -- run and
spin asv -- continuous.
Prerequisites
^^^^^^^^^^^^^
Begin by installing airspeed velocity <https://asv.readthedocs.io/en/stable/>_
in your development environment. Prior to installation, be sure to activate your
development environment, then if using venv you may install the requirement with::
source skimage-dev/bin/activate pip install asv
If you are using conda, then the command::
conda activate skimage-dev conda install asv
is more appropriate. Once installed, it is useful to run the command::
spin asv -- machine
To let airspeed velocity know more information about your machine.
Writing a benchmark
^^^^^^^^^^^^^^^^^^^
To write benchmark, add a file in the benchmarks directory which contains a
a class with one setup method and at least one method prefixed with time_.
The time_ method should only contain code you wish to benchmark.
Therefore it is useful to move everything that prepares the benchmark scenario
into the setup method. This function is called before calling a time_
method and its execution time is not factored into the benchmarks.
Take for example the TransformSuite benchmark:
.. code-block:: python
import numpy as np from skimage import transform
class TransformSuite: """Benchmark for transform routines in scikit-image."""
def setup(self):
self.image = np.zeros((2000, 2000))
idx = np.arange(500, 1500)
self.image[idx[::-1], idx] = 255
self.image[idx, idx] = 255
def time_hough_line(self):
result1, result2, result3 = transform.hough_line(self.image)
Here, the creation of the image is completed in the setup method, and not
included in the reported time of the benchmark.
It is also possible to benchmark features such as peak memory usage. To learn
more about the features, please refer to the official
airspeed velocity documentation <https://asv.readthedocs.io/en/latest/writing_benchmarks.html>_.
Also, the benchmark files need to be importable when benchmarking old versions of scikit-image. So if anything from scikit-image is imported at the top level, it should be done as:
.. code-block:: python
try:
from skimage import metrics
except ImportError:
pass
The benchmarks themselves don't need any guarding against missing features, only the top-level imports.
To allow tests of newer functions to be marked as "n/a" (not available) rather than "failed" for older versions, the setup method itself can raise a NotImplemented error. See the following example for the registration module:
.. code-block:: python
try:
from skimage import registration
except ImportError:
raise NotImplementedError("registration module not available")
Testing the benchmarks locally ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Prior to running the true benchmark, it is often worthwhile to test that the code is free of typos. To do so, you may use the command::
spin asv -- dev -b TransformSuite
Where the TransformSuite above will be run once in your current environment
to test that everything is in order.
Running your benchmark ^^^^^^^^^^^^^^^^^^^^^^
The command above is fast, but doesn't test the performance of the code
adequately. To do that you may want to run the benchmark in your current
environment to see the performance of your change as you are developing new
features. The command asv run -E existing will specify that you wish to run
the benchmark in your existing environment. This will save a significant amount
of time since building scikit-image can be a time consuming task::
spin asv -- run -E existing -b TransformSuite
Comparing results to main ^^^^^^^^^^^^^^^^^^^^^^^^^
Often, the goal of a PR is to compare the results of the modifications in terms
speed to a snapshot of the code that is in the main branch of the
scikit-image repository. The command asv continuous is of help here::
spin asv -- continuous main -b TransformSuite
This call will build out the environments specified in the asv.conf.json
file and compare the performance of the benchmark between your current commit
and the code in the main branch.
The output may look something like::
$ spin asv -- continuous main -b TransformSuite · Creating environments · Discovering benchmarks ·· Uninstalling from conda-py3.7-cython-numpy1.15-scipy ·· Installing 544c0fe3 <benchmark_docs> into conda-py3.7-cython-numpy1.15-scipy. · Running 4 total benchmarks (2 commits * 2 environments * 1 benchmarks) [ 0.00%] · For scikit-image commit 37c764cb <benchmark_docs~1> (round 1/2): [...] [100.00%] ··· ...ansform.TransformSuite.time_hough_line 33.2±2ms
BENCHMARKS NOT SIGNIFICANTLY CHANGED.
In this case, the differences between HEAD and main are not significant enough for airspeed velocity to report.
It is also possible to get a comparison of results for two specific revisions
for which benchmark results have previously been run via the asv compare
command::
spin asv -- compare v0.14.5 v0.17.2
Finally, one can also run ASV benchmarks only for a specific commit hash or
release tag by appending ^! to the commit or tag name. For example to run
the skimage.filter module benchmarks on release v0.17.2::
spin asv -- run -b Filter v0.17.2^!