This project is a community effort, and everyone is welcome to contribute !
If you are interested in contributing to Ignite, there are many ways to help out. Your contributions may fall into the following categories:
-
It helps us very much if you could
- Report issues you’re facing
- Give a 👍 on issues that others reported and that are relevant to you
- Spread a word about the project or simply ⭐ to say "I use it"
-
Answering queries on the issue tracker, investigating bugs and reviewing other developers’ pull requests are very valuable contributions that decrease the burden on the project maintainers.
-
You would like to improve the documentation. This is no less important than improving the library itself! If you find a typo in the documentation, do not hesitate to submit a GitHub pull request.
-
You would like propose a new feature and implement it
- Post about your intended feature, and we shall discuss the design and implementation. Once we agree that the plan looks good, go ahead and implement it.
-
You would like implement a feature or bug-fix for an outstanding issue
- Look at the issues labelled as "help wanted"
- Pick an issue and comment on the task that you want to work on this feature.
- If you need more context on a particular issue, please ask and we shall provide.
- Table of Contents
- Developing Ignite
- Install miniconda for your system.
- Create an isolated conda environment for pytorch-ignite:
conda create -n pytorch-ignite-dev python=3.8
- Activate the newly created environment:
conda activate pytorch-ignite-dev
- When developing please take care of preserving
.gitignore
file and make use of.git/info/exclude
to exclude custom files like:.idea
,.vscode
etc. - Please refer to github first contributions guidelines and don't hesitate to ask the pytorch-ignite community in case of any doubt.
- A good way to start is to tackle one of the good first issues.
To get the development installation with the necessary dependencies, run the following:
git clone https://github.com/pytorch/ignite.git
cd ignite
python setup.py develop
pip install -r requirements-dev.txt
bash ./tests/run_code_style.sh install
- ignite - Core library files
- engine - Module containing core classes like Engine, Events, State.
- handlers - Module containing out-of-the-box handlers
- metrics - Module containing out-of-the-box metrics
- contrib - Contrib module with other metrics, handlers classes that may require additional dependencies
- distributed - Module with helpers for distributed computations
- tests - Python unit tests
- examples - Examples and notebook tutorials
- docs - Documentation files
If you modify the code, you will most probably also need to code some tests to ensure the correct behaviour. We are using
pytest
to write our tests:
- naming convention for files
test_*.py
, e.g.test_precision.py
- naming of testing functions
def test_*
, e.g.def test_precision_on_random_data()
- if test function should run on GPU, please make sure to add
cuda
in the test name, e.g.def test_something_on_cuda()
. Additionally, we may want to decorate it with@pytest.mark.skipif(not torch.cuda.is_available(), reason="Skip if no GPU")
. For more examples, please see https://github.com/pytorch/ignite/blob/master/tests/ignite/engine/test_create_supervised.py - if test function checks distributed configuration, we have to mark the test as
@pytest.mark.distributed
and additional conditions depending on the intended checks. For example, please see https://github.com/pytorch/ignite/blob/master/tests/ignite/metrics/test_accuracy.py
- if test function should run on GPU, please make sure to add
New code should be compatible with Python 3.X versions. Once you finish implementing a feature or bugfix and tests, please run lint checking and tests:
To ensure the codebase complies with a style guide, we use flake8, black and isort tools to format and check codebase for compliance with PEP8.
If you choose not to use pre-commit, you can take advantage of IDE extensions configured to black format or invoke black manually to format files and commit them.
To install flake8
, black==21.12b0
, isort==5.7.0
and mypy
, please run
bash ./tests/run_code_style.sh install
To format files and commit changes:
# This should autoformat the files
bash ./tests/run_code_style.sh fmt
# If everything is OK, then commit
git add .
git commit -m "Added awesome feature"
To automate the process, we have configured the repo with pre-commit hooks to use black to autoformat the staged files to ensure every commit complies with a style guide. This requires some setup, which is described below:
- Install pre-commit in your python environment.
- Run pre-commit install that configures a virtual environment to invoke black, isort and flake8 on commits.
pip install pre-commit
pre-commit install
- When files are committed:
- If the stages files are not compliant with black, black will autoformat the staged files. If this were to happen, files should be staged and committed again. See example code below.
- If the staged files are not compliant with flake8, errors will be raised. These errors should be fixed and the files should be committed again. See example code below.
git add .
git commit -m "Added awesome feature"
# DONT'T WORRY IF ERRORS ARE RAISED.
# YOUR CODE IS NOT COMPLIANT WITH flake8, isort or black
# Fix any flake8 errors by following their suggestions
# isort and black will automatically format the files so they might look different, but you'll need to stage the files
# again for committing
# After fixing any flake8 errors
git add .
git commit -m "Added feature"
To run a specific test, for example test_terminate
from test_engine.py
:
pytest tests/ignite/engine/test_engine.py -vvv -k test_terminate
To run all tests with coverage (assuming installed pytest-cov
and pytest-xdist
):
bash tests/run_cpu_tests.sh
On Windows, distributed tests should be skipped
SKIP_DISTRIB_TESTS=1 bash tests/run_cpu_tests.sh
To run distributed tests only (assuming installed pytest-xdist
):
export WORLD_SIZE=2
CUDA_VISIBLE_DEVICES="" pytest --dist=each --tx $WORLD_SIZE*popen//python=python tests/ -m distributed -vvv
To run mypy to check the optional static type:
bash ./tests/run_code_style.sh mypy
To change any config for specif folder, please see the file mypy.ini
If everything is OK, please send a Pull Request to https://github.com/pytorch/ignite
If you are not familiar with creating a Pull Request, here are some guides:
- http://stackoverflow.com/questions/14680711/how-to-do-a-github-pull-request
- https://help.github.com/articles/creating-a-pull-request/
NOTE : When sending a PR, please kindly check if the changes are required to run in the CI.
For example, typo changes in CONTRIBUTING.md
, README.md
are not required to run in the CI.
So, please add [skip ci]
in the PR title to save the resources. Ignite has setup 3 CIs.
- GitHub Actions
- CircleCI
- Netlify
CircleCI is disabled on forked PR. So, please add
[skip actions]
for the changes which are not required to run on GitHub Actions,[skip netlify]
for the changes which are not required to run on Netlify PR Preview build, or[skip ci]
for the changes which are not required to run on any CI.
NOTE : Those skip statements are case sensitive, need open bracket [
and close bracket ]
.
And, Ignite has followed a convention of starting with skip
word.
First, make sure you have set upstream by running:
git remote add upstream https://github.com/pytorch/ignite
Then you can see if you have set up multiple remote correctly by running git remote -v
:
origin https://github.com/{YOUR_USERNAME}/ignite.git (fetch)
origin https://github.com/{YOUR_USERNAME}/ignite.git (push)
upstream https://github.com/pytorch/ignite (fetch)
upstream https://github.com/pytorch/ignite (push)
Now you can get the latest development into your forked repository with this:
git fetch upstream
git checkout master
git merge upstream/master
Ignite uses Google style
for formatting docstrings, specially from an example of Google style with Python 3 type annotations
and
.. versionadded::
directive for adding new classes, class methods, functions,.. versionchanged::
directive for adding new arguments, changing internal behaviours, fixing bugs and.. deprecated::
directive for deprecations.
Length of line inside docstrings block must be limited to 120 characters.
Please, follow the instructions to build and deploy the documentation locally.
cd docs
pip install -r requirements.txt
Katex is also needed to build the documentation.
To install katex, you need to have nodejs installed.
Optionaly, we can install nodejs/npm
using conda: conda install nodejs
.
Then you can install katex with npm or yarn (if installed).
npm install -g katex
# or if you use yarn package manager
yarn global add katex
cd docs
make html
Please, use python 3.X for the command below:
cd docs/build
python -m http.server <port>
# python -m http.server 1234
Then open the browser at localhost:<port>
(e.g. localhost:1234
) and click to html
folder.
PyTorch-Ignite uses Sphinx directives. Every code that needs to be tested
should be under .. testcode::
and expected output should be under
.. testoutput::
. For example:
.. testcode::
def process_function(engine, batch):
y_pred, y = batch
return y_pred, y
engine = Engine(process_function)
metric = SSIM(data_range=1.0)
metric.attach(engine, 'ssim')
preds = torch.rand([4, 3, 16, 16])
target = preds * 0.75
state = engine.run([[preds, target]])
print(state.metrics['ssim'])
.. testoutput::
0.9218971...
If the floating point results are needed for assertion and the results can vary per operating systems and PyTorch versions, we could assert the results up to 4 or 6 decimal places and match the rest of the results with ...
. Learn more about sphinx.ext.doctest
in the official documentation.
To make writing doctests easy, there are some configuratons defined in conf.py
. Search doctest_global_setup
in conf.py to see which variables and functions are available.
To run doctests locally:
cd docs
make html && make doctest