anchor.diff:        `globus transfer async-transfer --help` for an example
     - Comment liberally in source
     - Every command gets its own module, named after the command name
  -  - Use absolute imports everywhere
  -  - Avoid circular imports whenever possible -- given the choice between adding
  -      a new module or adding a circular import, add the new module
  -  - Import non-`globus_cli` modules and packages before importing from within
  -      `globus_cli`
     - Think very hard before adding a new dependency -- keep the dependencies of
         `globus_cli` as lightweight as possible
  -  - Use named parameters, not positional arguments
     - Use the verbs `create`, `show`, `update`, and `remove` for underlying API
         CRUD operations
   
  
positive.code: 
  Do it:
  
    - `make release` to build source dists, upload via twine, and tag the release
    - push the newly created version tag to GitHub
    - Ensure that `docs.globus.org` gets updated with new docs/changelog
        Procedure is set in that repo.
  
negative.code: 
    1. Clone repo:
       `git clone git@github.com:globus/globus-cli.git && cd globus-cli`
    2. Create a virtualenv for development. `make localdev`.
    3. Activate the resulting virtualenv with `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
  -----------------
  
  - All code is autoformatted with https://github.com/ambv/black[black] and
     https://github.com/timothycrosley/isort[isort]. You may run
      `make autoformat` to do this or configure these tools for use in your
      editor.
  - All code must pass `make test`, which runs linting and tests.
  
  NOTE: `black` requires python3.6+, so you may find it necessary to
  `make clean autoformat PYTHON_VERSION=python3.6` or equivalent.
  
  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
  