Skip to content

Latest commit

 

History

History
87 lines (63 loc) · 3.11 KB

CONTRIBUTING.adoc

File metadata and controls

87 lines (63 loc) · 3.11 KB
Raw

Contributing to the Globus SDK

First off, thank you so much for taking the time to contribute! 👍

Reporting Bugs & Requesting Features

  • Check if there’s a matching issue before opening a new issue or pull request

  • When possible, provide a code sample to reproduce bugs

Linting & Testing

Testing the SDK requires tox.

Once you have tox installed, you can run testing or linting on the repo with tox or tox -e lint. These are wrapped for convenience as make test and make lint as well.

All code must pass make lint test, which runs linting and tests.

Optional, but recommended linting setup

For the best development experience, we recommend setting up linting and autofixing integrations with your editor and git. These settings are optional, but strongly recommended.

Install pre-commit hooks

This automatically formats and lints your staged changes when you commit.

You must install pre-commit in order to use these hooks. Once you have the tool, just run

$ pre-commit install
Note
 If you need to bypass pre-commit hooks, you can commit with --no-verify
Integrate Linters & Fixers with your Editor

All code is autoformatted with black and isort, and checked with flake8.

Many editors, including vim, emacs, Atom, and VS Code have plugins or extensions that allow them to automatically run black and isort whenever a file is saved, and show errors flagged by flake8 in a separate pane, buffer, or sidebar.

Configuring such editor integrations will save you time and energy, as your work will usually pass linting before you even run make lint or commit your changes.

Expectations for Pull Requests

  • Make sure it merges cleanly. We may request that you rebase if your PR has merge conflicts.

  • List any issues closed by the pull request

  • Squash intermediate and fixup commits. We recommend running git rebase --interactive prior to submitting a pull request.

  • Add new work to the "Unreleased" section of the changelog

These are our guidelines for good commit messages:

  • No lines over 72 characters

  • No GitHub emoji — use your words

  • Reference issues and pull requests where appropriate

  • Present tense and imperative mood

Additional Recommendations

  • Try to use raw strings for docstrings — ensures that ReST won’t be confused by characters like \\

  • Use examples very liberally in documentation

  • Show where you imported from within the SDK. Start at least one example with from globus_sdk.modulename import ClassName on a page with docs for ClassName

  • Think very hard before adding a new dependency — keep the dependencies of globus_sdk as lightweight as possible