Generated banner for Python Pypi Package Builder
Generated logo for Python Pypi Package Builder

Python Pypi Package Builder

GitHubOfficialFirst committed by Dhruvpatel004Distributed by GitHub

  • Skill
  • Workflow
  • Software development
  • MIT
  • Low risk
  • Has scripts

From the author

End-to-end skill for building, testing, linting, versioning, and publishing a production-grade Python library to PyPI. Covers all four build backends (setuptools+setuptools_scm, hatchling, flit, poetry), PEP 440 versioning, semantic versioning, dynamic git-tag versioning, OOP/SOLID design, type hints (PEP 484/526/544/561), Trusted Publishing (OIDC), and the full PyPA packaging flow. Use for: creating Python packages, pip-installable SDKs, CLI tools, framework plugins, pyproject.toml setup, py.typed, setuptools_scm, semver, mypy, pre-commit, GitHub Actions CI/CD, or PyPI publishing.
— the description by Dhruvpatel004

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides an end-to-end framework for the entire Python packaging lifecycle. It covers selecting build backends (setuptools, hatchling, flit, poetry), configuring project structures, implementing robust versioning strategies, and setting up automated CI/CD pipelines. It emphasizes modern standards including PEP 440, PEP 561 type hints, and Trusted Publishing for secure PyPI releases.

What it does

  • Generates complete project directory layouts with a single command.
  • Configures pyproject.toml for various build backends and dependency management.
  • Implements automated versioning using git tags via setuptools_scm.
  • Sets up GitHub Actions for automated linting, testing, and PyPI publishing.
  • Provides patterns for SOLID design, type hinting, and plugin architectures.
  • Guides the user through the PyPA packaging flow from local build to release.

When to use it

  • When starting a new Python library, SDK, or CLI tool from scratch.
  • When refactoring an existing project to follow modern packaging standards.
  • When you need to set up automated CI/CD and PyPI publishing pipelines.
  • When you need guidance on choosing the right build backend for your project requirements.

Advantages

  • Standardizes project structure and configuration across different libraries.
  • Reduces manual overhead in versioning and release management.
  • Ensures high code quality through integrated linting, typing, and testing.
  • Promotes secure publishing practices using OIDC Trusted Publishing.

Usage examples

“I want to start a new Python SDK project. How should I structure it?”
The agent will guide you through selecting the src/ layout, choosing a build backend, and using the scaffold script to generate the initial files.
“How do I set up my Python library to publish to PyPI automatically?”
The agent will provide the necessary GitHub Actions configuration for Trusted Publishing and explain the required git-tagging release workflow.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/github/python-pypi-package-builder/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip python-pypi-package-builder.zip -d .agents/skills

Documentation by Dhruvpatel004

Python PyPI Package Builder Skill

A complete, battle-tested guide for building, testing, linting, versioning, typing, and publishing a production-grade Python library to PyPI — from first commit to community-ready release.

AI Agent Instruction: Read this entire file before writing a single line of code or creating any file. Every decision — layout, backend, versioning strategy, patterns, CI — has a decision rule here. Follow the decision trees in order. This skill applies to any Python package type (utility, SDK, CLI, plugin, data library). Do not skip sections.


Quick Navigation

Section in this fileWhat it covers
1. Skill TriggerWhen to load this skill
2. Package Type DecisionIdentify what you are building
3. Folder Structure Decisionsrc/ vs flat vs monorepo
4. Build Backend Decisionsetuptools / hatchling / flit / poetry
5. PyPA Packaging FlowThe canonical publish pipeline
6. Project Structure TemplatesFull layouts for every option
7. Versioning StrategyPEP 440, semver, dynamic vs static
Reference fileWhat it covers
references/pyproject-toml.mdAll four backend templates, setuptools_scm, py.typed, tool configs
references/library-patterns.mdOOP/SOLID, type hints, core class design, factory, protocols, CLI
references/testing-quality.mdconftest.py, unit/backend/async tests, ruff/mypy/pre-commit
references/ci-publishing.mdci.yml, publish.yml, Trusted Publishing, TestPyPI, CHANGELOG, release checklist
references/community-docs.mdREADME, docstrings, CONTRIBUTING, SECURITY, anti-patterns, master checklist
references/architecture-patterns.mdBackend system (plugin/strategy), config layer, transport layer, CLI, backend injection
references/versioning-strategy.mdPEP 440, SemVer, pre-release, setuptools_scm deep-dive, flit static, decision engine
references/release-governance.mdBranch strategy, branch protection, OIDC, tag author validation, prevent invalid tags
references/tooling-ruff.mdRuff-only setup (replaces black/isort), mypy config, pre-commit, asyncio_mode=auto

Scaffold script: run python skills/python-pypi-package-builder/scripts/scaffold.py --name your-package-name to generate the entire directory layout, stub files, and pyproject.toml in one command.


1. Skill Trigger

Load this skill whenever the user wants to:

  • Create, scaffold, or publish a Python package or library to PyPI

  • Build a pip-installable SDK, utility, CLI tool, or framework extension

  • Set up pyproject.toml, linting, mypy, pre-commit, or GitHub Actions for a Python project

  • Understand versioning (setuptools_scm, PEP 440, semver, static versioning)

  • Understand PyPA specs: py.typed, MANIFEST.in, RECORD, classifiers

  • Publish to PyPI using Trusted Publishing (OIDC) or API tokens

  • Refactor an existing package to follow modern Python packaging standards

  • Add type hints, protocols, ABCs, or dataclasses to a Python library

  • Apply OOP/SOLID design patterns to a Python package

  • Choose between build backends (setuptools, hatchling, flit, poetry)

Also trigger for phrases like: "build a Python SDK", "publish my library", "set up PyPI CI", "create a pip package", "how do I publish to PyPI", "pyproject.toml help", "PEP 561 typed", "setuptools_scm version", "semver Python", "PEP 440", "git tag release", "Trusted Publishing".


2. Package Type Decision

Identify what the user is building before writing any code. Each type has distinct patterns.

Decision Table
TypeCore PatternEntry PointKey DepsExample Packages
Utility libraryModule of pure functions + helpersImport API onlyMinimalarrow, humanize, boltons, more-itertools
API client / SDKClass with methods, auth, retry logicImport API onlyhttpx or requestsboto3, stripe-python, openai
CLI toolCommand functions + argument parser[project.scripts] or [project.entry-points]click or typerblack, ruff, httpie, rich
Framework pluginPlugin class, hook registration[project.entry-points."framework.plugin"]Framework deppytest-*, django-*, flask-*
Data processing libraryClasses + functional pipelineImport API onlyOptional: numpy, pandaspydantic, marshmallow, cerberus
Mixed / genericCombination of aboveVariesVariesMany real-world packages

Decision Rule: Ask the user if unclear. A package can combine types (e.g., SDK with a CLI entry point) — use the primary type for structural decisions and add secondary type patterns on top.

For implementation patterns of each type, see references/library-patterns.md.

Package Naming Rules
  • PyPI name: all lowercase, hyphens — my-python-library

  • Python import name: underscores — my_python_library

  • Check availability: https://pypi.org/search/ before starting

  • Avoid shadowing popular packages (verify pip install <name> fails first)


3. Folder Structure Decision

Decision Tree
Does the package have 5+ internal modules OR multiple contributors OR complex sub-packages?
├── YES → Use src/ layout
│         Reason: prevents accidental import of uninstalled code during development;
│         separates source from project root files; PyPA-recommended for large projects.
│
├── NO → Is it a single-module, focused package (e.g., one file + helpers)?
│         ├── YES → Use flat layout
│         └── NO (medium complexity) → Use flat layout, migrate to src/ if it grows
│
└── Is it multiple related packages under one namespace (e.g., myorg.http, myorg.db)?
          └── YES → Use namespace/monorepo layout
Quick Rule Summary
SituationUse
New project, unknown future sizesrc/ layout (safest default)
Single-purpose, 1–4 modulesFlat layout
Large library, many contributorssrc/ layout
Multiple packages in one repoNamespace / monorepo
Migrating old flat projectKeep flat; migrate to src/ at next major version

4. Build Backend Decision

Decision Tree
Does the user need version derived automatically from git tags?
├── YES → Use setuptools + setuptools_scm
│         (git tag v1.0.0 → that IS your release workflow)
│
└── NO → Does the user want an all-in-one tool (deps + build + publish)?
          ├── YES → Use poetry (v2+ supports standard [project] table)
          │
          └── NO → Is the package pure Python with no C extensions?
                    ├── YES, minimal config preferred → Use flit
                    │   (zero config, auto-discovers version from __version__)
                    │
                    └── YES, modern & fast preferred → Use hatchling
                        (zero-config, plugin system, no setup.py needed)

Does the package have C/Cython/Fortran extensions?
└── YES → MUST use setuptools (only backend with full native extension support)
Backend Comparison
BackendVersion sourceConfigC extensionsBest for
setuptools + setuptools_scmgit tags (automatic)pyproject.toml + optional setup.py shimYesProjects with git-tag releases; any complexity
hatchlingmanual or pluginpyproject.toml onlyNoNew pure-Python projects; fast, modern
flit__version__ in __init__.pypyproject.toml onlyNoVery simple, single-module packages
poetrypyproject.toml fieldpyproject.toml onlyNoTeams wanting integrated dep management

For all four complete pyproject.toml templates, see references/pyproject-toml.md.


5. PyPA Packaging Flow

This is the canonical end-to-end flow from source code to user install. Every step must be understood before publishing.

1. SOURCE TREE
   Your code in version control (git)
   └── pyproject.toml describes metadata + build system

2. BUILD
   python -m build
   └── Produces two artifacts in dist/:
       ├── *.tar.gz   → source distribution (sdist)
       └── *.whl      → built distribution (wheel) — preferred by pip

3. VALIDATE
   twine check dist/*
   └── Checks metadata, README rendering, and PyPI compatibility

4. TEST PUBLISH (first release only)
   twine upload --repository testpypi dist/*
   └── Verify: pip install --index-url https://test.pypi.org/simple/ your-package

5. PUBLISH
   twine upload dist/*          ← manual fallback
   OR GitHub Actions publish.yml  ← recommended (Trusted Publishing / OIDC)

6. USER INSTALL
   pip install your-package
   pip install "your-package[extra]"
Key PyPA Concepts
ConceptWhat it means
sdistSource distribution — your source + metadata; used when no wheel is available
wheel (.whl)Pre-built binary — pip extracts directly into site-packages; no build step
PEP 517/518Standard build system interface via pyproject.toml [build-system] table
PEP 621Standard [project] table in pyproject.toml; all modern backends support it
PEP 639license key as SPDX string (e.g., "MIT", "Apache-2.0") — not {text = "MIT"}
PEP 561py.typed empty marker file — tells mypy/IDEs this package ships type information

For complete CI workflow and publishing setup, see references/ci-publishing.md.


6. Project Structure Templates

your-package/
├── src/
│   └── your_package/
│       ├── __init__.py           # Public API: __all__, __version__
│       ├── py.typed              # PEP 561 marker — EMPTY FILE
│       ├── core.py               # Primary implementation
│       ├── client.py             # (API client type) or remove
│       ├── cli.py                # (CLI type) click/typer commands, or remove
│       ├── config.py             # Settings / configuration dataclass
│       ├── exceptions.py         # Custom exception hierarchy
│       ├── models.py             # Data classes, Pydantic models, TypedDicts
│       ├── utils.py              # Internal helpers (prefix _utils if private)
│       ├── types.py              # Shared type aliases and TypeVars
│       └── backends/             # (Plugin pattern) — remove if not needed
│           ├── __init__.py       # Protocol / ABC interface definition
│           ├── memory.py         # Default zero-dep implementation
│           └── redis.py          # Optional heavy implementation
├── tests/
│   ├── __init__.py
│   ├── conftest.py               # Shared fixtures
│   ├── unit/
│   │   ├── __init__.py
│   │   ├── test_core.py
│   │   ├── test_config.py
│   │   └── test_models.py
│   ├── integration/
│   │   ├── __init__.py
│   │   └── test_backends.py
│   └── e2e/                      # Optional: end-to-end tests
│       └── __init__.py
├── docs/                         # Optional: mkdocs or sphinx
├── scripts/
│   └── scaffold.py
├── .github/
│   ├── workflows/
│   │   ├── ci.yml
│   │   └── publish.yml
│   └── ISSUE_TEMPLATE/
│       ├── bug_report.md
│       └── feature_request.md
├── .pre-commit-config.yaml
├── pyproject.toml
├── CHANGELOG.md
├── CONTRIBUTING.md
├── SECURITY.md
├── LICENSE
├── README.md
└── .gitignore
B. Flat Layout (Small / focused packages)
your-package/
├── your_package/         # ← at root, not inside src/
│   ├── __init__.py
│   ├── py.typed
│   └── ... (same internal structure)
├── tests/
└── ... (same top-level files)
your-org/
├── packages/
│   ├── your-org-core/
│   │   ├── src/your_org/core/
│   │   └── pyproject.toml
│   ├── your-org-http/
│   │   ├── src/your_org/http/
│   │   └── pyproject.toml
│   └── your-org-cli/
│       ├── src/your_org/cli/
│       └── pyproject.toml
├── .github/workflows/
└── README.md

Each sub-package has its own pyproject.toml. They share the your_org namespace via PEP 420 implicit namespace packages (no __init__.py in the namespace root).

Internal Module Guidelines
FilePurposeWhen to include
__init__.pyPublic API surface; re-exports; __version__Always
py.typedPEP 561 typed-package marker (empty)Always
core.pyPrimary class / main logicAlways
config.pySettings dataclass or Pydantic modelWhen configurable
exceptions.pyException hierarchy (YourBaseError → specifics)Always
models.pyData models / DTOs / TypedDictsWhen data-heavy
utils.pyInternal helpers (not part of public API)As needed
types.pyShared TypeVar, TypeAlias, Protocol definitionsWhen complex typing
cli.pyCLI entry points (click/typer)CLI type only
backends/Plugin/strategy patternWhen swappable implementations
_compat.pyPython version compatibility shimsWhen 3.9–3.13 compat needed

7. Versioning Strategy

PEP 440 — The Standard
Canonical form:  N[.N]+[{a|b|rc}N][.postN][.devN]

Examples:
  1.0.0          Stable release
  1.0.0a1        Alpha (pre-release)
  1.0.0b2        Beta
  1.0.0rc1       Release candidate
  1.0.0.post1    Post-release (e.g., packaging fix only)
  1.0.0.dev1     Development snapshot (not for PyPI)
MAJOR.MINOR.PATCH

MAJOR: Breaking API change (remove/rename public function/class/arg)
MINOR: New feature, fully backward-compatible
PATCH: Bug fix, no API change
# How it works:
git tag v1.0.0          →  installed version = 1.0.0
git tag v1.1.0          →  installed version = 1.1.0
(commits after tag)     →  version = 1.1.0.post1  (suffix stripped for PyPI)

# In code — NEVER hardcode when using setuptools_scm:
from importlib.metadata import version, PackageNotFoundError
try:
    __version__ = version("your-package")
except PackageNotFoundError:
    __version__ = "0.0.0-dev"    # Fallback for uninstalled dev checkouts

Required pyproject.toml config:

[tool.setuptools_scm]
version_scheme = "post-release"
local_scheme   = "no-local-version"   # Prevents +g<hash> from breaking PyPI uploads

Critical: always set fetch-depth: 0 in every CI checkout step. Without full git history, setuptools_scm cannot find tags and the build version silently falls back to 0.0.0+dev.

Static versioning (flit, hatchling manual, poetry)
# your_package/__init__.py
__version__ = "1.0.0"    # Update this before every release
Version specifier best practices for dependencies
# In [project] dependencies:
"httpx>=0.24"            # Minimum version — PREFERRED for libraries
"httpx>=0.24,<1.0"       # Upper bound only when a known breaking change exists
"httpx==0.27.0"          # Pin exactly ONLY in applications, NOT libraries

# NEVER do this in a library — it breaks dependency resolution for users:
# "httpx~=0.24.0"        # Too tight
# "httpx==0.27.*"        # Fragile
Version bump → release flow
# 1. Update CHANGELOG.md — move [Unreleased] entries to [x.y.z] - YYYY-MM-DD
# 2. Commit the changelog
git add CHANGELOG.md
git commit -m "chore: prepare release vX.Y.Z"
# 3. Tag and push — this triggers publish.yml automatically
git tag vX.Y.Z
git push origin main --tags
# 4. Monitor GitHub Actions → verify on https://pypi.org/project/your-package/

For complete pyproject.toml templates for all four backends, see references/pyproject-toml.md.


Where to Go Next

After understanding decisions and structure:

  1. Set up pyproject.toml → references/pyproject-toml.md All four backend templates (setuptools+scm, hatchling, flit, poetry), full tool configs, py.typed setup, versioning config.

  2. Write your library code → references/library-patterns.md OOP/SOLID principles, type hints (PEP 484/526/544/561), core class design, factory functions, __init__.py, plugin/backend pattern, CLI entry point.

  3. Add tests and code quality → references/testing-quality.md conftest.py, unit/backend/async tests, parametrize, ruff/mypy/pre-commit setup.

  4. Set up CI/CD and publish → references/ci-publishing.md ci.yml, publish.yml with Trusted Publishing (OIDC, no API tokens), CHANGELOG format, release checklist.

  5. Polish for community/OSS → references/community-docs.md README sections, docstring format, CONTRIBUTING, SECURITY, issue templates, anti-patterns table, and master release checklist.

  6. Design backends, config, transport, CLI → references/architecture-patterns.md Backend system (plugin/strategy pattern), Settings dataclass, HTTP transport layer, CLI with click/typer, backend injection rules.

  7. Choose and implement a versioning strategy → references/versioning-strategy.md PEP 440 canonical forms, SemVer rules, pre-release identifiers, setuptools_scm deep-dive, flit static versioning, decision engine (DEFAULT/BEGINNER/MINIMAL).

  8. Govern releases and secure the publish pipeline → references/release-governance.md Branch strategy, branch protection rules, OIDC Trusted Publishing setup, tag author validation in CI, tag format enforcement, full governed publish.yml.

  9. Simplify tooling with Ruff → references/tooling-ruff.md Ruff-only setup replacing black/isort/flake8, mypy config, pre-commit hooks, asyncio_mode=auto (remove @pytest.mark.asyncio), migration guide.

Files

references/architecture-patterns.md

Architecture Patterns — Backend System, Config, Transport, CLI

Table of Contents

  1. Backend System (Plugin/Strategy Pattern)

  2. Config Layer (Settings Dataclass)

  3. Transport Layer (HTTP Client Abstraction)

  4. CLI Support

  5. Backend Injection in Core Client

  6. Decision Rules


1. Backend System (Plugin/Strategy Pattern)

Structure your backends/ sub-package with a clear base protocol, a zero-dependency default implementation, and optional heavy implementations behind extras.

Directory Layout
your_package/
  backends/
    __init__.py    # Exports BaseBackend + factory; holds the Protocol/ABC
    base.py        # Abstract base class (ABC) or Protocol definition
    memory.py      # Default, zero-dependency in-memory implementation
    redis.py       # Optional, heavier implementation (guarded by extras)
backends/base.py — Abstract Interface
# your_package/backends/base.py
from __future__ import annotations

from abc import ABC, abstractmethod


class BaseBackend(ABC):
    """Abstract storage/processing backend.

    All concrete backends must implement these methods.
    Never import heavy dependencies at module level — guard them inside the class.
    """

    @abstractmethod
    def get(self, key: str) -> str | None:
        """Retrieve a value by key. Return None when the key does not exist."""
        ...

    @abstractmethod
    def set(self, key: str, value: str, ttl: int | None = None) -> None:
        """Store a value with an optional TTL (seconds)."""
        ...

    @abstractmethod
    def delete(self, key: str) -> None:
        """Remove a key. No-op when the key does not exist."""
        ...

    def close(self) -> None:  # noqa: B027  (intentionally non-abstract)
        """Optional cleanup hook. Override in backends that hold connections."""
backends/memory.py — Default Zero-Dep Implementation
# your_package/backends/memory.py
from __future__ import annotations

import time
from collections.abc import Iterator
from contextlib import contextmanager
from threading import Lock

from .base import BaseBackend


class MemoryBackend(BaseBackend):
    """Thread-safe in-memory backend. No external dependencies required."""

    def __init__(self) -> None:
        self._store: dict[str, tuple[str, float | None]] = {}
        self._lock = Lock()

    def get(self, key: str) -> str | None:
        with self._lock:
            entry = self._store.get(key)
            if entry is None:
                return None
            value, expires_at = entry
            if expires_at is not None and time.monotonic() > expires_at:
                del self._store[key]
                return None
            return value

    def set(self, key: str, value: str, ttl: int | None = None) -> None:
        expires_at = time.monotonic() + ttl if ttl is not None else None
        with self._lock:
            self._store[key] = (value, expires_at)

    def delete(self, key: str) -> None:
        with self._lock:
            self._store.pop(key, None)
backends/redis.py — Optional Heavy Implementation
# your_package/backends/redis.py
from __future__ import annotations

from .base import BaseBackend


class RedisBackend(BaseBackend):
    """Redis-backed implementation. Requires: pip install your-package[redis]"""

    def __init__(self, url: str = "redis://localhost:6379/0") -> None:
        try:
            import redis as _redis
        except ImportError as exc:
            raise ImportError(
                "RedisBackend requires redis. "
                "Install it with: pip install your-package[redis]"
            ) from exc
        self._client = _redis.from_url(url, decode_responses=True)

    def get(self, key: str) -> str | None:
        return self._client.get(key)  # type: ignore[return-value]

    def set(self, key: str, value: str, ttl: int | None = None) -> None:
        if ttl is not None:
            self._client.setex(key, ttl, value)
        else:
            self._client.set(key, value)

    def delete(self, key: str) -> None:
        self._client.delete(key)

    def close(self) -> None:
        self._client.close()
backends/__init__.py — Public API + Factory
# your_package/backends/__init__.py
from __future__ import annotations

from .base import BaseBackend
from .memory import MemoryBackend

__all__ = ["BaseBackend", "MemoryBackend", "get_backend"]


def get_backend(backend_type: str = "memory", **kwargs: object) -> BaseBackend:
    """Factory: return the requested backend instance.

    Args:
        backend_type: "memory" (default) or "redis".
        **kwargs: Forwarded to the backend constructor.
    """
    if backend_type == "memory":
        return MemoryBackend()
    if backend_type == "redis":
        from .redis import RedisBackend  # Late import — redis is optional
        return RedisBackend(**kwargs)  # type: ignore[arg-type]
    raise ValueError(f"Unknown backend type: {backend_type!r}")

2. Config Layer (Settings Dataclass)

Centralise all configuration in one config.py module. Avoid scattering magic values and os.environ calls across the codebase.

config.py
# your_package/config.py
from __future__ import annotations

import os
from dataclasses import dataclass, field


@dataclass
class Settings:
    """All runtime configuration for your package.

    Attributes:
        api_key:  Authentication credential. Never log or expose this.
        timeout:  HTTP request timeout in seconds.
        retries:  Maximum number of retry attempts on transient failures.
        base_url: API base URL. Override in tests with a local server.
    """

    api_key: str
    timeout: int = 30
    retries: int = 3
    base_url: str = "https://api.example.com/v1"

    def __post_init__(self) -> None:
        if not self.api_key:
            raise ValueError("api_key must not be empty")
        if self.timeout < 1:
            raise ValueError("timeout must be >= 1")
        if self.retries < 0:
            raise ValueError("retries must be >= 0")

    @classmethod
    def from_env(cls) -> "Settings":
        """Construct Settings from environment variables.

        Required env var: YOUR_PACKAGE_API_KEY
        Optional env vars: YOUR_PACKAGE_TIMEOUT, YOUR_PACKAGE_RETRIES
        """
        api_key = os.environ.get("YOUR_PACKAGE_API_KEY", "")
        timeout = int(os.environ.get("YOUR_PACKAGE_TIMEOUT", "30"))
        retries = int(os.environ.get("YOUR_PACKAGE_RETRIES", "3"))
        return cls(api_key=api_key, timeout=timeout, retries=retries)
Using Pydantic (optional, for larger projects)
# your_package/config.py  — Pydantic v2 variant
from __future__ import annotations

from pydantic import Field
from pydantic_settings import BaseSettings


class Settings(BaseSettings):
    api_key: str = Field(..., min_length=1)
    timeout: int = Field(30, ge=1)
    retries: int = Field(3, ge=0)
    base_url: str = "https://api.example.com/v1"

    model_config = {"env_prefix": "YOUR_PACKAGE_"}

3. Transport Layer (HTTP Client Abstraction)

Isolate all HTTP concerns — headers, retries, timeouts, error parsing — in a dedicated transport/ sub-package. The core client depends on the transport abstraction, not on httpx or requests directly.

Directory Layout
your_package/
  transport/
    __init__.py    # Re-exports HttpTransport
    http.py        # Concrete httpx-based transport
transport/http.py
# your_package/transport/http.py
from __future__ import annotations

from typing import Any

import httpx

from ..config import Settings
from ..exceptions import YourPackageError, RateLimitError, AuthenticationError


class HttpTransport:
    """Thin httpx wrapper that centralises auth, retries, and error mapping."""

    def __init__(self, settings: Settings) -> None:
        self._settings = settings
        self._client = httpx.Client(
            base_url=settings.base_url,
            timeout=settings.timeout,
            headers={"Authorization": f"Bearer {settings.api_key}"},
        )

    def request(
        self,
        method: str,
        path: str,
        *,
        json: dict[str, Any] | None = None,
        params: dict[str, Any] | None = None,
    ) -> dict[str, Any]:
        """Send an HTTP request and return the parsed JSON body.

        Raises:
            AuthenticationError: on 401.
            RateLimitError: on 429.
            YourPackageError: on all other non-2xx responses.
        """
        response = self._client.request(method, path, json=json, params=params)
        self._raise_for_status(response)
        return response.json()

    def _raise_for_status(self, response: httpx.Response) -> None:
        if response.status_code == 401:
            raise AuthenticationError("Invalid or expired API key.")
        if response.status_code == 429:
            raise RateLimitError("Rate limit exceeded. Back off and retry.")
        if response.is_error:
            raise YourPackageError(
                f"API error {response.status_code}: {response.text[:200]}"
            )

    def close(self) -> None:
        self._client.close()

    def __enter__(self) -> "HttpTransport":
        return self

    def __exit__(self, *args: object) -> None:
        self.close()
Async variant
# your_package/transport/async_http.py
from __future__ import annotations

from typing import Any

import httpx

from ..config import Settings
from ..exceptions import YourPackageError, RateLimitError, AuthenticationError


class AsyncHttpTransport:
    """Async httpx wrapper. Use with `async with AsyncHttpTransport(...) as t:`."""

    def __init__(self, settings: Settings) -> None:
        self._settings = settings
        self._client = httpx.AsyncClient(
            base_url=settings.base_url,
            timeout=settings.timeout,
            headers={"Authorization": f"Bearer {settings.api_key}"},
        )

    async def request(
        self,
        method: str,
        path: str,
        *,
        json: dict[str, Any] | None = None,
        params: dict[str, Any] | None = None,
    ) -> dict[str, Any]:
        response = await self._client.request(method, path, json=json, params=params)
        self._raise_for_status(response)
        return response.json()

    def _raise_for_status(self, response: httpx.Response) -> None:
        if response.status_code == 401:
            raise AuthenticationError("Invalid or expired API key.")
        if response.status_code == 429:
            raise RateLimitError("Rate limit exceeded. Back off and retry.")
        if response.is_error:
            raise YourPackageError(
                f"API error {response.status_code}: {response.text[:200]}"
            )

    async def aclose(self) -> None:
        await self._client.aclose()

    async def __aenter__(self) -> "AsyncHttpTransport":
        return self

    async def __aexit__(self, *args: object) -> None:
        await self.aclose()

4. CLI Support

Add a CLI entry point via [project.scripts] in pyproject.toml.

pyproject.toml entry
[project.scripts]
your-cli = "your_package.cli:main"

After installation, the user can run your-cli --help directly from the terminal.

cli.py — Using Click
# your_package/cli.py
from __future__ import annotations

import sys

import click

from .config import Settings
from .core import YourClient


@click.group()
@click.version_option()
def main() -> None:
    """your-package CLI — interact with the API from the command line."""


@main.command()
@click.option("--api-key", envvar="YOUR_PACKAGE_API_KEY", required=True, help="API key.")
@click.option("--timeout", default=30, show_default=True, help="Request timeout (s).")
@click.argument("query")
def search(api_key: str, timeout: int, query: str) -> None:
    """Search the API and print results."""
    settings = Settings(api_key=api_key, timeout=timeout)
    client = YourClient(settings=settings)
    try:
        results = client.search(query)
        for item in results:
            click.echo(item)
    except Exception as exc:
        click.echo(f"Error: {exc}", err=True)
        sys.exit(1)
cli.py — Using Typer (modern alternative)
# your_package/cli.py
from __future__ import annotations

import typer

from .config import Settings
from .core import YourClient

app = typer.Typer(help="your-package CLI.")


@app.command()
def search(
    query: str = typer.Argument(..., help="Search query."),
    api_key: str = typer.Option(..., envvar="YOUR_PACKAGE_API_KEY"),
    timeout: int = typer.Option(30, help="Request timeout (s)."),
) -> None:
    """Search the API and print results."""
    settings = Settings(api_key=api_key, timeout=timeout)
    client = YourClient(settings=settings)
    results = client.search(query)
    for item in results:
        typer.echo(item)


def main() -> None:
    app()

5. Backend Injection in Core Client

Critical: always accept backend as a constructor argument. Never instantiate the backend inside the constructor without a fallback parameter — that makes testing impossible.

# your_package/core.py
from __future__ import annotations

from .backends.base import BaseBackend
from .backends.memory import MemoryBackend
from .config import Settings


class YourClient:
    """Primary client. Accepts an injected backend for testability.

    Args:
        settings: Resolved configuration. Use Settings.from_env() for production.
        backend:  Storage/processing backend. Defaults to MemoryBackend when None.
        timeout:  Deprecated — pass a Settings object instead.
        retries:  Deprecated — pass a Settings object instead.
    """

    def __init__(
        self,
        api_key: str | None = None,
        *,
        settings: Settings | None = None,
        backend: BaseBackend | None = None,
        timeout: int = 30,
        retries: int = 3,
    ) -> None:
        if settings is None:
            if api_key is None:
                raise ValueError("Provide either 'api_key' or 'settings'.")
            settings = Settings(api_key=api_key, timeout=timeout, retries=retries)
        self._settings = settings
        # CORRECT — default injected, not hardcoded
        self.backend: BaseBackend = backend if backend is not None else MemoryBackend()

    # ... methods
Anti-Pattern — Never Do This
# BAD: hardcodes the backend; impossible to swap in tests
class YourClient:
    def __init__(self, api_key: str) -> None:
        self.backend = MemoryBackend()          # ← no injection possible

# BAD: hardcodes the package name literal in imports
from your_package.backends.memory import MemoryBackend   # only fine in your_package itself
# use relative imports inside the package:
from .backends.memory import MemoryBackend               # ← correct

6. Decision Rules

Does the package interact with external state (cache, DB, queue)?
├── YES → Add backends/ with BaseBackend + MemoryBackend
│         Add optional heavy backends behind extras_require
│
└── NO → Skip backends/ entirely; keep core.py simple

Does the package call an external HTTP API?
├── YES → Add transport/http.py; inject via Settings
│
└── NO → Skip transport/

Does the package need a command-line interface?
├── YES, simple (1–3 commands) → Use argparse or click
│   Add [project.scripts] in pyproject.toml
│
├── YES, complex (sub-commands, plugins) → Use click or typer
│
└── NO → Skip cli.py

Does runtime behaviour depend on user-supplied config?
├── YES → Add config.py with Settings dataclass
│   Expose Settings.from_env() for production use
│
└── NO → Accept params directly in the constructor

Requirements and compatibility

Written for: GitHub Copilot

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs a command-line tool, Needs Python

Security

What our scanner noticed· Low risk

  • Instructions that use the network
  • Scripts that your agent may run

This skill includes scripts that your agent may run. Read them before you use it.

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

First committed by
GitHub avatar of Dhruvpatel004Dhruvpatel004
Publisher
GitHub (Official)
Distributed by
GitHub
Source
github/awesome-copilot · skills/python-pypi-package-builder · commit 797337f
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
Dhruvpatel004

AutoGineer is not affiliated with or endorsed by Dhruvpatel004 or GitHub.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download python-pypi-package-builder.zip