Getting Involved / Contributing¶
Ray is more than a framework for distributed applications but also an active community of developers, researchers, and folks that love machine learning.
Ask questions on our forum! The community is extremely active in helping people succeed in building their Ray applications.
You can join (and Star!) us on on GitHub.
Contributing to Ray¶
We welcome (and encourage!) all forms of contributions to Ray, including and not limited to:
Code reviewing of patches and PRs.
Documentation and examples.
Community participation in forums and issues.
Code readability and code comments to improve readability.
Test cases to make the codebase more robust.
Tutorials, blog posts, talks that promote the project.
What can I work on?¶
Examples of features to contribute¶
We encourage both the developers and users of optimization libraries to contribute Search Algorithms (tune.suggest) to Tune wrapping around them. Search Algorithms allow Tune’s users to take advantage of algorithms contained in external libraries while benefitting from a unified API and other Tune features.
For implementation details, please refer to Custom Search Algorithms (tune.suggest.Searcher).
Setting up your development environment¶
To edit the Ray source code, you’ll want to checkout the repository and also build Ray from source. Follow these instructions for building a local copy of Ray to easily make changes.
Submitting and Merging a Contribution¶
There are a couple steps to merge a contribution.
First merge the most recent version of master into your development branch.
git remote add upstream https://github.com/ray-project/ray.git git pull upstream master
Make sure all existing tests pass.
If introducing a new feature or patching a bug, be sure to add new test cases in the relevant file in ray/python/ray/tests/.
Document the code. Public functions need to be documented, and remember to provide an usage example if applicable.
Request code reviews from other contributors and address their comments. One fast way to get reviews is to help review others’ code so that they return the favor. You should aim to improve the code as much as possible before the review. We highly value patches that can get in without extensive reviews.
Reviewers will merge and approve the pull request; be sure to ping them if the pull request is getting stale.
Even though we have hooks to run unit tests automatically for each pull request, we recommend you to run unit tests locally beforehand to reduce reviewers’ burden and speedup review process.
Documentation should be documented in Google style format.
Testing for Python development¶
Suppose that one of the tests in a file of tests, e.g.,
python/ray/tests/test_basic.py, is failing. You can run just that
test file locally as follows:
python -m pytest -v python/ray/tests/test_basic.py
However, this will run all of the tests in the file, which can take some time. To run a specific test that is failing, you can do the following instead:
pytest test_file.py -v -k [test substring]
When running tests, usually only the first test failure matters. A single test failure often triggers the failure of subsequent tests in the same file.
# Stop after first failure. pytest test_file.py -x
Testing for C++ development¶
To compile and run all C++ tests, you can run:
bazel test $(bazel query 'kind(cc_test, ...)')
Alternatively, you can also run one specific C++ test. You can use:
bazel test $(bazel query 'kind(cc_test, ...)') --test_filter=ClientConnectionTest --test_output=streamed
Lint and Formatting¶
Python 3.7 is recommended. You will run into flake8 issues with Python 3.8.
We also have tests for code formatting and linting that need to pass before merge.
yapf==0.23, flake8, flake8-quotes.
pip install yapf==0.23.0)
pip install flake8==3.7.7)
pip install flake8-quotes)
On MacOS X, don’t use HomeBrew to install
clang-format, as the only version available is too new.
You can run the following locally:
An output like the following indicates failure:
WARNING: clang-format is not installed! # This is harmless From https://github.com/ray-project/ray * branch master -> FETCH_HEAD python/ray/util/sgd/tf/tf_runner.py:4:1: F401 'numpy as np' imported but unused # Below is the failure
In addition, there are other formatting checkers for components like the following:
Python README format:
cd python python setup.py check --restructuredtext --strict --metadata
Understanding CI test jobs¶
The Ray project automatically runs continuous integration (CI) tests once a PR is opened using Buildkite with multiple CI test jobs.
The CI test folder contains all integration test scripts and they
invoke other test scripts via
bazel-based test or other bash
scripts. Some of the examples include:
- Raylet integration tests commands:
bazel test //:core_worker_test
- Bazel test command:
bazel test --build_tests_only //:all
- Ray serving test commands:
If a CI build exception doesn’t appear to be related to your change, please visit this link to check recent tests known to be flaky.
Becoming a Reviewer¶
We identify reviewers from active contributors. Reviewers are individuals who not only actively contribute to the project and are also willing to participate in the code review of new contributions. A pull request to the project has to be reviewed by at least one reviewer in order to be merged. There is currently no formal process, but active contributors to Ray will be solicited by current reviewers.
More Resources for Getting Involved¶
Ray is more than a framework for distributed applications but also an active community of developers, researchers, and folks that love machine learning. Here’s a list of tips for getting involved with the Ray community:
Join our community Slack to discuss Ray!
Star and follow us on on GitHub.
To post questions or feature requests, check out the Discussion Board!
Follow us and spread the word on Twitter!
Join our Meetup Group to connect with others in the community!
Use the [ray] tag on StackOverflow to ask and answer questions about Ray usage
These tips are based off of the TVM contributor guide.