# ...
```

Check that the new tests pass:

```bash
hatch run test
```

## Things to Consider

We've described some basic steps for creating a custom Python SDK, but there are many facets to an SDK project besides code that contribute to its success or failure. For any publicly available Python library, you should consider such aspects as documentation, linting, and licensing.

### Documentation

To focus on the nuts and bolts of a custom Python SDK, this guide does not cover developing an SDK's documentation. But documentation is critical to ensure your users can easily pick up your library and use it productively. Without good documentation, developers may opt not to use your SDK at all.

All SDK functions, parameters, and behaviors should be documented, and creating beautiful, functional documentation is an essential part of making your SDK usable. You can roll your own documentation and add Markdown to the project `README.md` file or use a popular library like [Sphinx](https://www.sphinx-doc.org/) that includes such features as automatic highlighting, themes, and HTML or PDF outputs.

### Linting

Consistently formatted code improves readability and encourages contributions that are not jarring in the context of the existing codebase. While this guide doesn't cover linting, linting your SDK code should form part of creating an SDK.

For best results, linting should be as far-reaching and opinionated as possible, with little to zero default configuration required. Some popular options for linting include [Flake8](https://pypi.org/project/flake8/), [Ruff](https://github.com/astral-sh/ruff), and [Black](https://pypi.org/project/black/).

### Licensing

A project's license can significantly influence the type and number of potential open-source contributors. Choosing the right license for your SDK is key. Do you want your SDK's license to be community-orientated? Simple and permissive? To preserve a particular philosophy on enforcing the sharing of code modifications? In this example, we selected the MIT license for simplicity and ease of use. If you're unsure which license would best suit your needs, consider using a tool like [Choose a license](https://choosealicense.com/).

### Other Endpoints

This tutorial covered a basic SDK for two endpoints. Consider that real-world SDKs can have many more endpoints and features. You can use the same principles to add more endpoints to your SDK.

### Authentication Methods

If APIs use OAuth 2.0 or other authentication methods, you'll need to add authentication methods to your SDK. You can use libraries like [Authlib](https://docs.authlib.org/en/latest/) to handle OAuth 2.0 authentication.

### Pagination

If the API returns paginated results, you'll need to handle pagination in your SDK.

### Retries and Backoff

If the API is rate-limited or has intermittent failures, you'll need to add retry and backoff logic to your SDK.

## Build the Package

Now that we have a working SDK, we can build the package for distribution.

```bash
hatch build
```

Hatch will build the package and output the distribution files:

```bash
────────────────────────────────────── sdist ───────────────────────────────────────
dist/ecom_sdk-0.0.1.tar.gz
────────────────────────────────────── wheel ───────────────────────────────────────
dist/ecom_sdk-0.0.1-py3-none-any.whl
```

You should now have a `./dist` directory containing your source (`.tar.gz`) and built (`.whl`) distributions:

```bash
.
├── dist
│   ├── ecom_sdk-0.0.1-py3-none-any.whl
│   └── ecom_sdk-0.0.1.tar.gz
```

## Upload the SDK to the Distribution Archives

We now have just enough to upload the SDK to the PyPI test repo at test.pypi.org.

To upload the build to TestPyPI, you need:

1. A test PyPI account. Go to [https://test.pypi.org/account/register/](https://test.pypi.org/account/register/) to register.

2. A PyPI API token. Create one at [https://test.pypi.org/manage/account/#api-tokens](https://test.pypi.org/manage/account/#api-tokens), setting the "Scope" to "Entire account".

<Callout title="PyPI API Tokens" type="warning">
  Don't close the token page until you have copied and saved the token. For
  security reasons, the token will only appear once.
</Callout>

If you plan to automate SDK publishing in your CI/CD pipeline, you should create per-project tokens. For automated releasing using CI/CD, it is recommended that you create per-project API tokens.

Finally, publish the package distribution files by executing:

```bash
hatch publish -r test
```

The `-r test` switch specifies that we are using the TestPyPI repository.

Hatch will ask for a username and credentials. Use `__token__` as the username (to indicate that we are using a token value rather than a username) and paste your PyPI API token in the credentials field.

```bash
hatch publish -r test                                                                                                                                            ⇐ [15:13]═
Enter your username [__token__]: __token__
Enter your credentials: (paste your token here)
dist/ecom_sdk-0.0.1-py3-none-any.whl ... success
dist/ecom_sdk-0.0.1.tar.gz ... success

[ecom-sdk]
https://test.pypi.org/project/ecom-sdk/0.0.1/
```

Your shiny new package is now available to all your new Python customers!

The `ecom-sdk` python package can now be installed using:

```bash
pip install --index-url https://test.pypi.org/simple/ --no-deps ecom-sdk
```

We use the `--index-url` switch to specify the TestPyPI repo instead of the default live repo. We use the `--no-deps` switch because the test PyPI repo doesn't have all dependencies (because it's a test repo) and the `pip install` command would fail otherwise.

## Automatically Create Language-Idiomatic SDKs From Your API Specification

We've taken the first few steps in creating a Python SDK but as you can see, we've barely scratched the surface. It takes a good deal of work and dedication to iterate on an SDK project and get it built right. Then comes the maintenance phase, dealing with pull requests, and triaging issues from contributors.

You might want to consider automating the creation of SDKs with a managed service like Speakeasy. You can quickly get up and running with SDKs in nine languages with best practices baked in and maintain them automatically with the latest language and security updates.