Thanks for considering contributing to Composer!
Issues tagged with good first issue are great options to start contributing.
If you have questions, join us on Slack -- we'll be happy to help you!
We welcome contributions for bug fixes, new efficient methods you'd like to contribute to the community, or new models and datasets!
Have a new algorithm you'd like to contribute to the library as part of your research? We welcome any PRs, and recommend filing an issue with the proposed method or reaching out on Slack first!
To set up the development environment in your local box, run the commands below.
1. Install the dependencies needed for testing and linting the code:
pip install -e '.[all]'
2. Configure pre-commit, which automatically formats code before each commit:
pre-commit install
To submit a contribution:
1. Fork a copy of the Composer library to your own account.
2. Clone your fork locally and add the mosaicml repo as a remote repository:
git clone [email protected]:<github_id>/composer.git
cd composer
git remote add upstream https://github.com/mosaicml/composer.git
3. Create a branch and make your proposed changes.
git checkout -b cool-new-feature
4. When you are ready, submit a pull request into the composer repository! If merged, we'll reach out to send you some free swag :)
We have some rough guidelines that will make your PR easier to review and more likely to get smoothly merged. Please don't let uncertainty or difficulty with any of these things stop you from opening a PR! We are happy to help you through them :)
- Self-contained title and description. Please include a concise title and clear PR description. The title should allow someone to understand what the PR changes or does at a glance. The description should allow someone to understand the contents of the PR without looking at the code.
- If the PR affects output that is displayed to a user of Composer (e.g. console logging or experiment tracker reporting), please include screenshots showing what the new output looks like. UX is important!
- Include tests. If you are fixing a bug, please add a test that would've caught the bug. If you are adding a new feature, please add unit tests that test the various components of the feature, and also a test that tests the full functionality of the feature.
- Please consider whether your changes affect the example notebooks or large parts of the code base, and run the daily tests locally if so (
pytest -m 'daily and not remote and not gpu and not vision and not doctest'
) pre-commit
should help you handle formatting and type checking, but please do make sure you have it installed as described above.
Composer uses pytest-codeblocks to test all example code snippets. The pytest-codeblocks repository explains how to annotate code snippets, which supports most pytest
configurations. For example, if a test requires model training, the GPU mark (<!--pytest.mark.skip-->
) should be applied.
To test your changes locally, run:
make test
# run CPU testsmake test-gpu
# run GPU testscd docs && make doctest
# run doctests
Some of our checks test distributed training as well. To test these, run:
make test-dist WORLD_SIZE=2
# run 2-cpu distributed testsmake test-dist-gpu WORLD_SIZE=2
# run 2-gpu distributed tests
These tests run with the composer
launcher. We also support WORLD_SIZE=1
, which would run the tests with the composer
launcher on a single device.
See the Makefile for more information.
If you want to run pre-commit hooks manually, which check for code formatting and type annotations, run pre-commit run --all-files
See the Composer Style Guide for guidelines on how to structure and format your code.
Composer aims to annotate all functions with type annotations (introduced in PEP 526). Don't worry if you are not a Python typing expert; put in the pull request, and we'll help you with getting the code into shape.