base-api-client

Reusable base API client package for Datasdr services.

Package

• Distribution: datasdr-base-api-client
• Import path: datasdr_base_api_client

What it provides

• BaseHTTPClient for async HTTP operations with retry-on-auth-failure support.
• TokenProvider abstraction and token provider implementations:
  • StaticTokenProvider
  • PlainTokenProvider
  • CallableTokenProvider
  • ServiceTokenProvider

Install

From this repository:

pip install .

Or as a dependency from another service once published:

pip install datasdr-base-api-client

Minimal usage

from datasdr_base_api_client import BaseHTTPClient, StaticTokenProvider

client = BaseHTTPClient(
		base_url="https://api.example.com",
		token_provider=StaticTokenProvider("my-token"),
)

Publish (private PyPI)

Set credentials and publish to Datasdr private repository:

PYPI_PUBLISHER_USERNAME="<username>" \
PYPI_PUBLISHER_PASSWORD="<password>" \
make package-publish-private

This uses:

TWINE_USERNAME="$PYPI_PUBLISHER_USERNAME" \
TWINE_PASSWORD="$PYPI_PUBLISHER_PASSWORD" \
python -m twine upload --repository-url "https://pypi.devops.datasdr.com/datasdr/shared/" --non-interactive dist/*

GitHub Actions publish

Workflow file: .github/workflows/publish-private-pypi.yml

• Triggers on:
  • pull_request to main (build only)
  • push to main (build only)
• Publishing uses repository secrets:
  • PYPI_PUBLISHER_USERNAME
  • PYPI_PUBLISHER_PASSWORD
• Repository URL uses a repository variable:
  • PRIVATE_PYPI_REPOSITORY_URL
  • Default fallback: https://pypi.devops.datasdr.com/datasdr/shared/

This workflow is validation-only (build + twine check) and does not publish.

Automated release with Commitizen

Workflow file: .github/workflows/release-private-pypi.yml

• Triggers on push to main.
• Uses Commitizen to:
  • bump version in pyproject.toml
  • update CHANGELOG.md
  • create a Git tag
• Pushes the bump commit/tag and publishes package to private PyPI.
• dist/ artifacts are built during the workflow run; dist/ is not committed to the repository.

Changelog best practice

Keep CHANGELOG.md versioned in the repository. This is the recommended approach for libraries because consumers can read version history directly in source control, releases, and packaged artifacts. Build artifacts can include changelog content, but should not be the only source of truth.