Skip to content

Latest commit

 

History

History
89 lines (62 loc) · 2.98 KB

CONTRIBUTING.adoc

File metadata and controls

89 lines (62 loc) · 2.98 KB

Contributing to the Globus CLI

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

If you want to do local development, you can setup a development virtualenv in .venv by running make localdev.

Reporting Bugs & Requesting Features

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

  • When possible, provide a usage example to reproduce bugs

Developer Setup

These steps should help you setup a development environment for the Globus CLI.

  1. Create a fork of the globus/globus-cli repository.

    Follow https://github.com/globus/globus-cli/fork in a browser.

  2. Clone your forked repository & navigate to it.

    git clone <fork-repo-url> && cd globus-cli

  3. Install dependencies in a local virtualenv for development.

    make install

  4. Activate the resulting virtualenv.

    source .venv/bin/activate

You should now have, in your virtualenv, the globus-cli installed, pointed at your local copy of the repo. globus will invoke code directly out of the repo. You can write and test commands interactively in this setup.

Linting & Testing

We use tox to run tests and pre-commit to run (optional) pre-commit hooks. Use pre-commit install to setup the hooks.

All code is autoformatted with black and isort. You may run make lint to do this or configure these tools for use in your editor.

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.

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

  • All options should have descriptive help text

  • For complex functionality, include sample usage in the helptext for the relevant command. If it’s a specific flag or feature that has complex behavior, make it a separate section of the help text. See globus transfer async-transfer --help for an example

  • Comment liberally in source

  • Every command gets its own module, named after the command name

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

  • Use the verbs create, show, update, and remove for underlying API CRUD operations

Releasing a Version

If you are a CLI maintainer, you need to be able to do a release. For steps, see the RELEASING doc.