python-packaging
wshobson/agents
Create and publish distributable Python packages with modern project structure and PyPI integration.
What is python-packaging?
Comprehensive guide to structuring, building, and distributing Python packages using pyproject.toml, setuptools, and PyPI. Use this when creating libraries, CLI tools, or any code you need to package for distribution.
- Set up proper package directory structures (source layout, flat layout, multi-package projects)
- Configure pyproject.toml with PEP 517/518/621 standards for metadata and build requirements
- Create wheel (.whl) and source distributions (.tar.gz) for PyPI publishing
- Define entry points for command-line tools and executable scripts
- Manage dependencies and optional dependency groups (dev, extras, etc.)
- Support editable installs and namespace packages
How to install python-packaging
npx skills add https://github.com/wshobson/agents --skill python-packaging- Python 3.8 or higher
- pip or another package installer
- Basic understanding of Python modules and imports
How to use python-packaging
- 1.Choose a package structure (source layout recommended for libraries, flat layout for simpler projects)
- 2.Create pyproject.toml with build-system requirements and project metadata (name, version, description, dependencies)
- 3.Organize source code in src/package_name/ or package_name/ directory with __init__.py files
- 4.Add README.md, LICENSE, and .gitignore to project root
- 5.Create tests/ directory with test files matching your package structure
- 6.Build distributions using a build tool (e.g., python -m build)
- 7.Test locally with pip install -e . for editable installs
- 8.Upload to TestPyPI first to verify configuration
Use cases
- Publishing a Python library to PyPI for public use
- Building a command-line tool with entry points and distributing it
- Setting up a private package repository for internal team use
- Creating installable packages with pinned dependencies for reproducibility
- Organizing multi-package projects with shared configuration
- Python library developers
- CLI tool creators
- DevOps engineers packaging internal tools
- Open-source maintainers
- Teams managing private Python packages
python-packaging FAQ
Source layout (src/package_name/) is recommended for libraries—it prevents accidentally importing from source and provides better test isolation. Flat layout (package_name/) is simpler but less professional and can cause import issues.
No. Modern Python packaging uses pyproject.toml with PEP 621 metadata. setup.py is legacy; pyproject.toml is the current standard and sufficient for most projects.
setuptools is the most widely compatible. hatchling is modern and opinionated, flit is lightweight for pure Python, and poetry adds dependency management. Choose based on your needs.
Define entry_points in pyproject.toml under [project.scripts] with the command name and module:function reference. setuptools will create executable scripts when the package is installed.
TestPyPI is a sandbox for testing package uploads and configuration before publishing to the real PyPI. Use it to verify your setup works before releasing publicly.
Full instructions (SKILL.md)
Source of truth, from wshobson/agents.
name: python-packaging description: Create distributable Python packages with proper project structure, setup.py/pyproject.toml, and publishing to PyPI. Use when packaging Python libraries, creating CLI tools, or distributing Python code.
Python Packaging
Comprehensive guide to creating, structuring, and distributing Python packages using modern packaging tools, pyproject.toml, and publishing to PyPI.
When to Use This Skill
- Creating Python libraries for distribution
- Building command-line tools with entry points
- Publishing packages to PyPI or private repositories
- Setting up Python project structure
- Creating installable packages with dependencies
- Building wheels and source distributions
- Versioning and releasing Python packages
- Creating namespace packages
- Implementing package metadata and classifiers
Core Concepts
1. Package Structure
- Source layout:
src/package_name/(recommended) - Flat layout:
package_name/(simpler but less flexible) - Package metadata: pyproject.toml, setup.py, or setup.cfg
- Distribution formats: wheel (.whl) and source distribution (.tar.gz)
2. Modern Packaging Standards
- PEP 517/518: Build system requirements
- PEP 621: Metadata in pyproject.toml
- PEP 660: Editable installs
- pyproject.toml: Single source of configuration
3. Build Backends
- setuptools: Traditional, widely used
- hatchling: Modern, opinionated
- flit: Lightweight, for pure Python
- poetry: Dependency management + packaging
4. Distribution
- PyPI: Python Package Index (public)
- TestPyPI: Testing before production
- Private repositories: JFrog, AWS CodeArtifact, etc.
Quick Start
Minimal Package Structure
my-package/
├── pyproject.toml
├── README.md
├── LICENSE
├── src/
│ └── my_package/
│ ├── __init__.py
│ └── module.py
└── tests/
└── test_module.py
Minimal pyproject.toml
[build-system]
requires = ["setuptools>=61.0"]
build-backend = "setuptools.build_meta"
[project]
name = "my-package"
version = "0.1.0"
description = "A short description"
authors = [{name = "Your Name", email = "you@example.com"}]
readme = "README.md"
requires-python = ">=3.8"
dependencies = [
"requests>=2.28.0",
]
[project.optional-dependencies]
dev = [
"pytest>=7.0",
"black>=22.0",
]
Package Structure Patterns
Pattern 1: Source Layout (Recommended)
my-package/
├── pyproject.toml
├── README.md
├── LICENSE
├── .gitignore
├── src/
│ └── my_package/
│ ├── __init__.py
│ ├── core.py
│ ├── utils.py
│ └── py.typed # For type hints
├── tests/
│ ├── __init__.py
│ ├── test_core.py
│ └── test_utils.py
└── docs/
└── index.md
Advantages:
- Prevents accidentally importing from source
- Cleaner test imports
- Better isolation
pyproject.toml for source layout:
[tool.setuptools.packages.find]
where = ["src"]
Pattern 2: Flat Layout
my-package/
├── pyproject.toml
├── README.md
├── my_package/
│ ├── __init__.py
│ └── module.py
└── tests/
└── test_module.py
Simpler but:
- Can import package without installing
- Less professional for libraries
Pattern 3: Multi-Package Project
project/
├── pyproject.toml
├── packages/
│ ├── package-a/
│ │ └── src/
│ │ └── package_a/
│ └── package-b/
│ └── src/
│ └── package_b/
└── tests/
Detailed patterns and worked examples
Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient.
Related skills
More from wshobson/agents and the wider catalog.

python-performance-optimization
Profile and optimize Python code to identify bottlenecks and improve performance.

python-project-structure
Design well-organized Python projects with clear module boundaries, explicit public interfaces, and maintainable directory structures.

python-resilience
Automatic retries, exponential backoff, and fault-tolerant decorators for resilient Python services.

python-resource-management
Manage Python resources deterministically with context managers, cleanup patterns, and streaming.

python-testing-patterns
Implement comprehensive testing strategies with pytest, fixtures, mocking, and test-driven development.

python-type-safety
Add robust Python type hints, generics, and protocols with strict mypy/pyright checking guidance.