Python Pypi Package Builder
GitHubOfficialFirst committed by Dhruvpatel004Distributed by GitHub
- Skill
- Workflow
- Software development
- MIT
- Low risk
- Has scripts
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
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/github/python-pypi-package-builder/downloadUnzip 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 file | What it covers |
|---|---|
| 1. Skill Trigger | When to load this skill |
| 2. Package Type Decision | Identify what you are building |
| 3. Folder Structure Decision | src/ vs flat vs monorepo |
| 4. Build Backend Decision | setuptools / hatchling / flit / poetry |
| 5. PyPA Packaging Flow | The canonical publish pipeline |
| 6. Project Structure Templates | Full layouts for every option |
| 7. Versioning Strategy | PEP 440, semver, dynamic vs static |
| Reference file | What it covers |
|---|---|
references/pyproject-toml.md | All four backend templates, setuptools_scm, py.typed, tool configs |
references/library-patterns.md | OOP/SOLID, type hints, core class design, factory, protocols, CLI |
references/testing-quality.md | conftest.py, unit/backend/async tests, ruff/mypy/pre-commit |
references/ci-publishing.md | ci.yml, publish.yml, Trusted Publishing, TestPyPI, CHANGELOG, release checklist |
references/community-docs.md | README, docstrings, CONTRIBUTING, SECURITY, anti-patterns, master checklist |
references/architecture-patterns.md | Backend system (plugin/strategy), config layer, transport layer, CLI, backend injection |
references/versioning-strategy.md | PEP 440, SemVer, pre-release, setuptools_scm deep-dive, flit static, decision engine |
references/release-governance.md | Branch strategy, branch protection, OIDC, tag author validation, prevent invalid tags |
references/tooling-ruff.md | Ruff-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 projectUnderstand versioning (
setuptools_scm, PEP 440, semver, static versioning)Understand PyPA specs:
py.typed,MANIFEST.in,RECORD, classifiersPublish 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
| Type | Core Pattern | Entry Point | Key Deps | Example Packages |
|---|---|---|---|---|
| Utility library | Module of pure functions + helpers | Import API only | Minimal | arrow, humanize, boltons, more-itertools |
| API client / SDK | Class with methods, auth, retry logic | Import API only | httpx or requests | boto3, stripe-python, openai |
| CLI tool | Command functions + argument parser | [project.scripts] or [project.entry-points] | click or typer | black, ruff, httpie, rich |
| Framework plugin | Plugin class, hook registration | [project.entry-points."framework.plugin"] | Framework dep | pytest-*, django-*, flask-* |
| Data processing library | Classes + functional pipeline | Import API only | Optional: numpy, pandas | pydantic, marshmallow, cerberus |
| Mixed / generic | Combination of above | Varies | Varies | Many 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-libraryPython import name: underscores —
my_python_libraryCheck 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 layoutQuick Rule Summary
| Situation | Use |
|---|---|
| New project, unknown future size | src/ layout (safest default) |
| Single-purpose, 1–4 modules | Flat layout |
| Large library, many contributors | src/ layout |
| Multiple packages in one repo | Namespace / monorepo |
| Migrating old flat project | Keep 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
| Backend | Version source | Config | C extensions | Best for |
|---|---|---|---|---|
setuptools + setuptools_scm | git tags (automatic) | pyproject.toml + optional setup.py shim | Yes | Projects with git-tag releases; any complexity |
hatchling | manual or plugin | pyproject.toml only | No | New pure-Python projects; fast, modern |
flit | __version__ in __init__.py | pyproject.toml only | No | Very simple, single-module packages |
poetry | pyproject.toml field | pyproject.toml only | No | Teams 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
| Concept | What it means |
|---|---|
| sdist | Source 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/518 | Standard build system interface via pyproject.toml [build-system] table |
| PEP 621 | Standard [project] table in pyproject.toml; all modern backends support it |
| PEP 639 | license key as SPDX string (e.g., "MIT", "Apache-2.0") — not {text = "MIT"} |
| PEP 561 | py.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
A. src/ Layout (Recommended default for new projects)
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
└── .gitignoreB. 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)C. Namespace / Monorepo Layout (Multiple related packages)
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.mdEach 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
| File | Purpose | When to include |
|---|---|---|
__init__.py | Public API surface; re-exports; __version__ | Always |
py.typed | PEP 561 typed-package marker (empty) | Always |
core.py | Primary class / main logic | Always |
config.py | Settings dataclass or Pydantic model | When configurable |
exceptions.py | Exception hierarchy (YourBaseError → specifics) | Always |
models.py | Data models / DTOs / TypedDicts | When data-heavy |
utils.py | Internal helpers (not part of public API) | As needed |
types.py | Shared TypeVar, TypeAlias, Protocol definitions | When complex typing |
cli.py | CLI entry points (click/typer) | CLI type only |
backends/ | Plugin/strategy pattern | When swappable implementations |
_compat.py | Python version compatibility shims | When 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)Semantic Versioning (recommended)
MAJOR.MINOR.PATCH
MAJOR: Breaking API change (remove/rename public function/class/arg)
MINOR: New feature, fully backward-compatible
PATCH: Bug fix, no API changeDynamic versioning with setuptools_scm (recommended for git-tag workflows)
# 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 checkoutsRequired pyproject.toml config:
[tool.setuptools_scm]
version_scheme = "post-release"
local_scheme = "no-local-version" # Prevents +g<hash> from breaking PyPI uploadsCritical: 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 releaseVersion 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.*" # FragileVersion 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:
Set up
pyproject.toml→references/pyproject-toml.mdAll four backend templates (setuptools+scm, hatchling, flit, poetry), full tool configs,py.typedsetup, versioning config.Write your library code →
references/library-patterns.mdOOP/SOLID principles, type hints (PEP 484/526/544/561), core class design, factory functions,__init__.py, plugin/backend pattern, CLI entry point.Add tests and code quality →
references/testing-quality.mdconftest.py, unit/backend/async tests, parametrize, ruff/mypy/pre-commit setup.Set up CI/CD and publish →
references/ci-publishing.mdci.yml,publish.ymlwith Trusted Publishing (OIDC, no API tokens), CHANGELOG format, release checklist.Polish for community/OSS →
references/community-docs.mdREADME sections, docstring format, CONTRIBUTING, SECURITY, issue templates, anti-patterns table, and master release checklist.Design backends, config, transport, CLI →
references/architecture-patterns.mdBackend system (plugin/strategy pattern), Settings dataclass, HTTP transport layer, CLI with click/typer, backend injection rules.Choose and implement a versioning strategy →
references/versioning-strategy.mdPEP 440 canonical forms, SemVer rules, pre-release identifiers, setuptools_scm deep-dive, flit static versioning, decision engine (DEFAULT/BEGINNER/MINIMAL).Govern releases and secure the publish pipeline →
references/release-governance.mdBranch strategy, branch protection rules, OIDC Trusted Publishing setup, tag author validation in CI, tag format enforcement, full governedpublish.yml.Simplify tooling with Ruff →
references/tooling-ruff.mdRuff-only setup replacing black/isort/flake8, mypy config, pre-commit hooks, asyncio_mode=auto (remove @pytest.mark.asyncio), migration guide.
Files
- ATTRIBUTION.mdAdded by AutoGineer897 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md18.7 KiB
- references/architecture-patterns.md15.8 KiB
- references/ci-publishing.md7.9 KiB
- references/community-docs.md13.0 KiB
- references/library-patterns.md17.7 KiB
- references/pyproject-toml.md13.0 KiB
- references/release-governance.md10.4 KiB
- references/testing-quality.md6.4 KiB
- references/tooling-ruff.md9.2 KiB
- references/versioning-strategy.md10.9 KiB
- scripts/scaffold.pyScript22.0 KiB
references/library-patterns.md
Library Core Patterns, OOP/SOLID, and Type Hints
Table of Contents
OOP & SOLID Principles
Type Hints Best Practices
Core Class Design
Factory / Builder Pattern
Configuration Pattern
__init__.py— explicit public APIOptional Backends (Plugin Pattern)
1. OOP & SOLID Principles
Apply these principles to produce maintainable, testable, extensible packages. Do not over-engineer — apply the principle that solves a real problem, not all of them at once.
S — Single Responsibility Principle
Each class/module should have one reason to change.
# BAD: one class handles data, validation, AND persistence
class UserManager:
def validate(self, user): ...
def save_to_db(self, user): ...
def send_email(self, user): ...
# GOOD: split responsibilities
class UserValidator:
def validate(self, user: User) -> None: ...
class UserRepository:
def save(self, user: User) -> None: ...
class UserNotifier:
def notify(self, user: User) -> None: ...O — Open/Closed Principle
Open for extension, closed for modification. Use protocols or ABCs as extension points.
from abc import ABC, abstractmethod
class StorageBackend(ABC):
"""Define the interface once; never modify it for new implementations."""
@abstractmethod
def get(self, key: str) -> str | None: ...
@abstractmethod
def set(self, key: str, value: str) -> None: ...
class MemoryBackend(StorageBackend): # Extend by subclassing
...
class RedisBackend(StorageBackend): # Add new impl without touching StorageBackend
...L — Liskov Substitution Principle
Subclasses must be substitutable for their base. Never narrow a contract in a subclass.
class BaseProcessor:
def process(self, data: dict) -> dict: ...
# BAD: raises TypeError for valid dicts — breaks substitutability
class StrictProcessor(BaseProcessor):
def process(self, data: dict) -> dict:
if not data:
raise TypeError("Must have data") # Base never raised this
# GOOD: accept what base accepts, fulfill the same contract
class StrictProcessor(BaseProcessor):
def process(self, data: dict) -> dict:
if not data:
return {} # Graceful — same return type, no new exceptionsI — Interface Segregation Principle
Prefer small, focused protocols over large monolithic ABCs.
# BAD: forces all implementers to handle read+write+delete+list
class BigStorage(ABC):
@abstractmethod
def read(self): ...
@abstractmethod
def write(self): ...
@abstractmethod
def delete(self): ...
@abstractmethod
def list_all(self): ... # Not every backend needs this
# GOOD: separate protocols — clients depend only on what they need
from typing import Protocol
class Readable(Protocol):
def read(self, key: str) -> str | None: ...
class Writable(Protocol):
def write(self, key: str, value: str) -> None: ...
class Deletable(Protocol):
def delete(self, key: str) -> None: ...D — Dependency Inversion Principle
High-level modules depend on abstractions (protocols/ABCs), not concrete implementations.
Pass dependencies in via __init__ (constructor injection).
# BAD: high-level class creates its own dependency
class ApiClient:
def __init__(self) -> None:
self._cache = RedisCache() # Tightly coupled to Redis
# GOOD: depend on the abstraction; inject the concrete at call site
class ApiClient:
def __init__(self, cache: CacheBackend) -> None: # CacheBackend is a Protocol
self._cache = cache
# User code (or tests):
client = ApiClient(cache=RedisCache()) # Real
client = ApiClient(cache=MemoryCache()) # TestComposition Over Inheritance
Prefer delegating to contained objects over deep inheritance chains.
# Prefer this (composition):
class YourClient:
def __init__(self, backend: StorageBackend, http: HttpTransport) -> None:
self._backend = backend
self._http = http
# Avoid this (deep inheritance):
class YourClient(BaseClient, CacheMixin, RetryMixin, LoggingMixin):
... # Fragile, hard to test, MRO confusionException Hierarchy
Always define a base exception for your package; layer specifics below it.
# your_package/exceptions.py
class YourPackageError(Exception):
"""Base exception — catch this to catch any package error."""
class ConfigurationError(YourPackageError):
"""Raised when package is misconfigured."""
class AuthenticationError(YourPackageError):
"""Raised on auth failure."""
class RateLimitError(YourPackageError):
"""Raised when rate limit is exceeded."""
def __init__(self, retry_after: int) -> None:
self.retry_after = retry_after
super().__init__(f"Rate limited. Retry after {retry_after}s.")2. Type Hints Best Practices
Follow PEP 484 (type hints), PEP 526 (variable annotations), PEP 544 (protocols), PEP 561 (typed packages). These are not optional for a quality library.
from __future__ import annotations # Enables PEP 563 deferred evaluation — always add this
# For ARGUMENTS: prefer abstract / protocol types (more flexible for callers)
from collections.abc import Iterable, Mapping, Sequence, Callable
def process_items(items: Iterable[str]) -> list[int]: ... # ✓ Accepts any iterable
def process_items(items: list[str]) -> list[int]: ... # ✗ Too restrictive
# For RETURN TYPES: prefer concrete types (callers know exactly what they get)
def get_names() -> list[str]: ... # ✓ Concrete
def get_names() -> Iterable[str]: ... # ✗ Caller can't index it
# Use X | Y syntax (Python 3.10+), not Union[X, Y] or Optional[X]
def find(key: str) -> str | None: ... # ✓ Modern
def find(key: str) -> Optional[str]: ... # ✗ Old style
# None should be LAST in unions
def get(key: str) -> str | int | None: ... # ✓
# Avoid Any — it disables type checking entirely
def process(data: Any) -> Any: ... # ✗ Loses all safety
def process(data: dict[str, object]) -> dict[str, object]: # ✓
# Use object instead of Any when a param accepts literally anything
def log(value: object) -> None: ... # ✓
# Avoid Union return types — they require isinstance() checks at every call site
def get_value() -> str | int: ... # ✗ Forces callers to branchProtocols vs ABCs
from typing import Protocol, runtime_checkable
from abc import ABC, abstractmethod
# Use Protocol when you don't control the implementer classes (duck typing)
@runtime_checkable # Makes isinstance() checks work at runtime
class Serializable(Protocol):
def to_dict(self) -> dict[str, object]: ...
# Use ABC when you control the class hierarchy and want default implementations
class BaseBackend(ABC):
@abstractmethod
async def get(self, key: str) -> str | None: ...
def get_or_default(self, key: str, default: str) -> str:
result = self.get(key)
return result if result is not None else defaultTypeVar and Generics
from typing import TypeVar, Generic
T = TypeVar("T")
T_co = TypeVar("T_co", covariant=True) # For read-only containers
class Repository(Generic[T]):
"""Type-safe generic repository."""
def __init__(self, model_class: type[T]) -> None:
self._store: list[T] = []
def add(self, item: T) -> None:
self._store.append(item)
def get_all(self) -> list[T]:
return list(self._store)dataclasses for data containers
from dataclasses import dataclass, field
@dataclass(frozen=True) # frozen=True → immutable, hashable (good for configs/keys)
class Config:
api_key: str
timeout: int = 30
headers: dict[str, str] = field(default_factory=dict)
def __post_init__(self) -> None:
if not self.api_key:
raise ValueError("api_key must not be empty")TYPE_CHECKING guard (avoid circular imports)
from __future__ import annotations
from typing import TYPE_CHECKING
if TYPE_CHECKING:
from your_package.models import HeavyModel # Only imported during type checking
def process(model: "HeavyModel") -> None:
...Overload for multiple signatures
from typing import overload
@overload
def get(key: str, default: None = ...) -> str | None: ...
@overload
def get(key: str, default: str) -> str: ...
def get(key: str, default: str | None = None) -> str | None:
... # Single implementation handles both3. Core Class Design
The main class of your library should have a clear, minimal __init__, sensible defaults for all
parameters, and raise TypeError / ValueError early for invalid inputs. This prevents confusing
errors at call time rather than at construction.
# your_package/core.py
from __future__ import annotations
from your_package.exceptions import YourPackageError
class YourClient:
"""
Main entry point for <your purpose>.
Args:
api_key: Required authentication credential.
timeout: Request timeout in seconds. Defaults to 30.
retries: Number of retry attempts. Defaults to 3.
Raises:
ValueError: If api_key is empty or timeout is non-positive.
Example:
>>> from your_package import YourClient
>>> client = YourClient(api_key="sk-...")
>>> result = client.process(data)
"""
def __init__(
self,
api_key: str,
timeout: int = 30,
retries: int = 3,
) -> None:
if not api_key:
raise ValueError("api_key must not be empty")
if timeout <= 0:
raise ValueError("timeout must be positive")
self._api_key = api_key
self.timeout = timeout
self.retries = retries
def process(self, data: dict) -> dict:
"""
Process data and return results.
Args:
data: Input dictionary to process.
Returns:
Processed result as a dictionary.
Raises:
YourPackageError: If processing fails.
"""
...Design rules
Accept all config in
__init__, not scattered across method calls.Validate at construction time — fail fast with a clear message.
Keep
__init__signatures stable. Adding new keyword-only args with defaults is backwards compatible. Removing or reordering positional args is a breaking change.
4. Factory / Builder Pattern
Use a factory function when users need to create pre-configured instances. This avoids cluttering
__init__ with a dozen keyword arguments and keeps the common case simple.
# your_package/factory.py
from __future__ import annotations
from your_package.core import YourClient
from your_package.backends.memory import MemoryBackend
def create_client(
api_key: str,
*,
timeout: int = 30,
retries: int = 3,
backend: str = "memory",
backend_url: str | None = None,
) -> YourClient:
"""
Factory that returns a configured YourClient.
Args:
api_key: Required API key.
timeout: Request timeout in seconds.
retries: Number of retry attempts.
backend: Storage backend type. One of 'memory' or 'redis'.
backend_url: Connection URL for the chosen backend.
Example:
>>> client = create_client(api_key="sk-...", backend="redis", backend_url="redis://localhost")
"""
if backend == "redis":
from your_package.backends.redis import RedisBackend
_backend = RedisBackend(url=backend_url or "redis://localhost:6379")
else:
_backend = MemoryBackend()
return YourClient(api_key=api_key, timeout=timeout, retries=retries, backend=_backend)Why a factory, not a class method? Both work. A standalone factory function is easier to mock in tests and avoids coupling the factory logic into the class itself.
5. Configuration Pattern
Use a dataclass (or Pydantic BaseModel) to hold configuration. This gives you free validation,
helpful error messages, and a single place to document every option.
# your_package/config.py
from __future__ import annotations
from dataclasses import dataclass, field
@dataclass
class YourSettings:
"""
Configuration for YourClient.
Attributes:
timeout: HTTP timeout in seconds.
retries: Number of retry attempts on transient errors.
base_url: Base API URL.
"""
timeout: int = 30
retries: int = 3
base_url: str = "https://api.example.com"
extra_headers: dict[str, str] = field(default_factory=dict)
def __post_init__(self) -> None:
if self.timeout <= 0:
raise ValueError("timeout must be positive")
if self.retries < 0:
raise ValueError("retries must be non-negative")If you need environment variable loading, use pydantic-settings as an optional dependency —
declare it in [project.optional-dependencies], not as a required dep.
6. __init__.py — Explicit Public API
A well-defined __all__ is not just style — it tells users (and IDEs) exactly what's part of your
public API, and prevents accidental imports of internal helpers as part of your contract.
# your_package/__init__.py
"""your-package: <one-line description>."""
from importlib.metadata import version, PackageNotFoundError
try:
__version__ = version("your-package")
except PackageNotFoundError:
__version__ = "0.0.0-dev"
from your_package.core import YourClient
from your_package.config import YourSettings
from your_package.exceptions import YourPackageError
__all__ = [
"YourClient",
"YourSettings",
"YourPackageError",
"__version__",
]Rules:
Only export what users are supposed to use. Internal helpers go in
_utils.pyor submodules.Keep imports at the top level of
__init__.pyshallow — avoid importing heavy optional deps (likeredis) at module level. Import them lazily inside the class or function that needs them.__version__is always part of the public API — it enablesyour_package.__version__for debugging.
7. Optional Backends (Plugin Pattern)
This pattern lets your package work out-of-the-box (no extra deps) with an in-memory backend, while letting advanced users plug in Redis, a database, or any custom storage.
5.1 Abstract base class — defines the interface
# your_package/backends/__init__.py
from abc import ABC, abstractmethod
class BaseBackend(ABC):
"""Abstract storage backend interface.
Implement this to add a custom backend (database, cache, etc.).
"""
@abstractmethod
async def get(self, key: str) -> str | None:
"""Retrieve a value by key. Returns None if not found."""
...
@abstractmethod
async def set(self, key: str, value: str, ttl: int | None = None) -> None:
"""Store a value. Optional TTL in seconds."""
...
@abstractmethod
async def delete(self, key: str) -> None:
"""Delete a key."""
...5.2 Memory backend — zero extra deps
# your_package/backends/memory.py
from __future__ import annotations
import asyncio
import time
from your_package.backends import BaseBackend
class MemoryBackend(BaseBackend):
"""Thread-safe in-memory backend. Works out of the box — no extra dependencies."""
def __init__(self) -> None:
self._store: dict[str, tuple[str, float | None]] = {}
self._lock = asyncio.Lock()
async def get(self, key: str) -> str | None:
async 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.time() > expires_at:
del self._store[key]
return None
return value
async def set(self, key: str, value: str, ttl: int | None = None) -> None:
async with self._lock:
expires_at = time.time() + ttl if ttl is not None else None
self._store[key] = (value, expires_at)
async def delete(self, key: str) -> None:
async with self._lock:
self._store.pop(key, None)5.3 Redis backend — raises clear ImportError if not installed
The key design: import redis lazily inside __init__, not at module level. This way,
import your_package never fails even if redis isn't installed.
# your_package/backends/redis.py
from __future__ import annotations
from your_package.backends import BaseBackend
try:
import redis.asyncio as aioredis
except ImportError as exc:
raise ImportError(
"Redis backend requires the redis extra:\n"
" pip install your-package[redis]"
) from exc
class RedisBackend(BaseBackend):
"""Redis-backed storage for distributed/multi-process deployments."""
def __init__(self, url: str = "redis://localhost:6379") -> None:
self._client = aioredis.from_url(url, decode_responses=True)
async def get(self, key: str) -> str | None:
return await self._client.get(key)
async def set(self, key: str, value: str, ttl: int | None = None) -> None:
await self._client.set(key, value, ex=ttl)
async def delete(self, key: str) -> None:
await self._client.delete(key)5.4 How users choose a backend
# Default: in-memory, no extra deps needed
from your_package import YourClient
client = YourClient(api_key="sk-...")
# Redis: pip install your-package[redis]
from your_package.backends.redis import RedisBackend
client = YourClient(api_key="sk-...", backend=RedisBackend(url="redis://localhost:6379"))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
Dhruvpatel004
- 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