Python Packaging
SkillAI & modelsA skill that guides an AI agent through packaging Python code for distribution. It covers project structure, pyproject.toml metadata, build backends like setuptools and hatchling, and building wheels. It also covers publishing to PyPI or private repositories and versioning releases.
Then ask your AI: use the Python Packaging skill
Details
Instructions available. Your AI can read the instructions. Execution depends on the setup they require.
Account requirements not reviewed. Check the skill instructions before use; Ahel provides instructions and does not run this skill.
No other account needed.
Have a Python project with code you want to distribute.
What your AI can do with it
- Set up a src or flat project layout for a Python package
- Write pyproject.toml metadata and build system requirements
- Choose a build backend such as setuptools, hatchling, flit, or poetry
- Build wheels and source distributions
- Publish packages to PyPI, TestPyPI, or private repositories
- Add entry points for command-line tools
Getting started
- Have a Python project with code you want to distribute.
- Create a pyproject.toml with project metadata and a build-system section.
- Place your package under src/package_name/ or use a flat layout.
- Build a wheel and source distribution with your chosen build backend.
- Upload the built distributions to PyPI or a private repository.
What this skill tells your AI
The instructions your AI receives, as published by wshobson/agents in plugins/python-development/skills/python-packaging/SKILL.md and read by Ahel’s review.
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.
Signals
- GitHub stars
- 40k
- Forks
- 4k
- Last commit
- Oct 2026
Ahel review
K1binfo
installs-packages (in references/advanced-patterns.md)K1binfo
installs-packages (in references/details.md)
Automated review, not a security audit. Ruleset v1+k2.
Questions
- What project structure does it recommend?
- It recommends the source layout with code under src/package_name/, which prevents accidentally importing from source and gives cleaner test imports. A flat layout with package_name/ at the top level is also described as simpler but less flexible.
- Which build backends does it cover?
- It covers setuptools, described as traditional and widely used, hatchling as modern and opinionated, flit as lightweight for pure Python, and poetry for dependency management plus packaging.
- Can it publish to a private repository?
- Yes. It covers publishing to PyPI, TestPyPI for testing before production, and private repositories such as JFrog and AWS CodeArtifact.
Advanced
- Item type
- skill
- Key
python-packaging-wshobson- Source
- github.com/wshobson/agents
Related picks
Skill · sickn33
The pick for Pythonpython-design-patterns
Skill · wshobson
The pick for Pythonaws-architecture-diagram
Skill · awslabs
The pick for AWSaws-health-events
Skill · aws
The pick for AWSdetecting-aws-cloudtrail-anomalies
Skill · mukul975
The pick for AWSendly-aws-apigateway
Skill · viant
The pick for AWS