Python Packaging

SkillAI & models

A 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.

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

  1. Have a Python project with code you want to distribute.
  2. Create a pyproject.toml with project metadata and a build-system section.
  3. Place your package under src/package_name/ or use a flat layout.
  4. Build a wheel and source distribution with your chosen build backend.
  5. 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