Skip to content

Latest commit

 

History

History
125 lines (81 loc) · 4.17 KB

CONTRIBUTING.md

File metadata and controls

125 lines (81 loc) · 4.17 KB

Python Development Guide

This guide covers Python-specific setup and development for the CDP SDK.

Contents

Development Setup

The CDP SDK uses Python 3.10 or higher.

You can run the following to check your Python version.

python --version

Then, set up your virtualenv and install dependencies by running the following.

make setup
make install

Updating the SDK to use a new version of the OpenAPI specification

The OpenAPI specification and OpenAPI clients are automatically generated by the Update OpenAPI GitHub Action.

Pull the code:

  • Pull the update_openapi branch locally and check out the local branch
  • Run git reset --soft HEAD~1 && git commit -am "Updated OpenAPI client" to recommit as a signed commit

Wrap the OpenAPI client functionality:

Add new EVM functionality in cdp/evm_client.py and Solana functionality in cdp/solana_client.py.

To wrap an openapi client function, follow these conventions:

  1. Name the function but remove _evm or _solana from the function name.
  2. Remove the x_wallet_auth parameter, since our auth middleware handles this automatically.
  3. Rename x_idempotency_key to idempotency_key
  4. Take in the underlying request body parameters directly in the function. For example,
request_evm_faucet(
        RequestEvmFaucetRequest(
            address=evm_account.address, network="base-sepolia", token="eth"
        )
    )

becomes

request_faucet(address=evm_account.address, network="base-sepolia", token="eth")

Add unit tests in the test/ folder, following the conventions of other unit tests. Update the E2E tests in test_e2e.py file.

Testing

Running Testing

Run make test to run all unit tests in the SDK. If you want to run e2e tests, run make e2e.

Example Scripts

The CDP SDK includes several runnable examples. See examples/README.md for more information. When you make a change to the SDK code, your change will automatically take effect when you run an example.

Code Style

We use ESLint and Prettier for linting and formatting. Run:

# Format code
make format

# Lint code
make lint

# Fix linting issues
make lint-fix

Changelog

We use towncrier to manage the changelog.

Changelog entries should be in the past tense, and they should be as specific as possible. Some examples of good changelog entries:

  • Added a getAccount method to the EVM client
  • Fixed a bug preventing wallet balances to be formatted correctly

Changelog entries are stored in the changelog.d directory. Each changelog entry is stored as a markdown file named after the type of change it is and the Pull Request number it is associated with. For example, a bug fix associated with PR #123 would be stored as changelog.d/123.bugfix.md. First create the Pull Request, and then use the PR number in the changelog entry filename.

To add a changelog entry, you can create the changelog entry file yourself, or use towncrier to create it for you. For example, to create a changelog entry for a bug fix associated with PR #123, run the following command from the package you are making a change to:

cd python

# Create a new changelog entry file for a bugfix relating to PR #123
uv run towncrier create --content "Fixed a bug" 123.bugfix.md

# Or, create a new changelog entry for a feature relating to PR #124
uv run towncrier create --content "Added a new feature" 124.feature.md

This will create a new changelog entry in the changelog.d directory, which should be committed along with the changes in your Pull Request.

The types of changes you can add are:

  • feature
  • bugfix
  • doc
  • removal
  • misc

For more info, see the towncrier docs.