Python Pypi Package Builder

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

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

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

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

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

5. PyPA Packaging Flow