python-packaging-patterns

Configure Python project packaging with pyproject.toml, src layouts, and publishing workflows.

Updated May 16, 2026
One-click install
npx skills add https://github.com/organvm-i-theoria/_agent-ontology --skill python-packaging-patterns-organvm-i-theoria
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: python-packaging-patterns
Source: https://github.com/organvm-i-theoria/_agent-ontology/tree/main/.agents/skills/python-packaging-patterns
Command: npx skills add https://github.com/organvm-i-theoria/_agent-ontology --skill python-packaging-patterns-organvm-i-theoria

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Python projects often ship with inconsistent layouts, duplicated version strings, and fragile dependency specs that break installs and publishing. This Skill provides concrete patterns for structuring packages, configuring pyproject.toml, and managing dependencies so distribution works reliably. ## Core Features & Use Cases - Project Layout Guidance: Choose between src layout and flat layout with clear rationale for testability and import safety. - pyproject.toml Configuration: Set up build backends (hatchling, setuptools, flit, poetry-core), optional dependency groups, entry points, and tool configs for Ruff, Pytest, and Mypy. - Versioning & Publishing: Apply single-source versioning, CalVer for system packages, lockfile generation with uv or pip-tools, and PyPI publishing including trusted publishing via GitHub Actions. - Use Case: When starting a new Python library, use this Skill to scaffold a src-layout project with hatchling, dev dependency groups, and a console script entry point ready for editable install and PyPI release. ## Quick Start Set up a new Python package with a src layout, hatchling build backend, and dev dependencies configured in pyproject.toml.

Frequently Asked Questions about python-packaging-patterns

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I structure a Python project for packaging?▼

Use the src layout with your package under src/my_package/, tests in a separate tests/ directory, and pyproject.toml at the root. This prevents accidental imports from the working directory and forces installation before testing, catching packaging errors early.

Which build backend should I use in pyproject.toml?▼

Hatchling is the recommended default for its speed, minimal config, and monorepo support. Use setuptools for legacy projects or C extensions, flit for simple pure-Python packages, and poetry-core when managing dependencies with Poetry.

How do I manage a single version source in Python packaging?▼

Declare dynamic = ["version"] in pyproject.toml and point the build backend at your package's __init__.py, for example with [tool.hatch.version] path = "src/my_package/__init__.py". Keep __version__ defined only in that one file.

Should libraries pin exact dependency versions?▼

No. Libraries should use loose compatible bounds like >=1.0,<2.0 in pyproject.toml to avoid dependency conflicts for consumers. Exact pins and lockfiles belong to applications and CI, generated with uv pip compile or pip-tools.

How do I publish a Python package to PyPI?▼

Build distributions with python -m build, then upload with twine or the pypa/gh-action-pypi-publish GitHub Action. Trusted publishing via GitHub Actions is preferred over long-lived API tokens.