Generated banner for Python Packaging
Generated logo for Python Packaging

Python Packaging

Seth HobsonCommunityCreated by Seth Hobson

  • Skill
  • Tool integration
  • Software development
  • MIT
  • Low risk

From the author

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.
— the description by Seth Hobson

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to Python packaging, focusing on modern standards like PEP 517, 518, and 621. It covers project layout strategies, configuration via pyproject.toml, dependency management, and the creation of distributable formats like wheels and source distributions. The guide includes patterns for handling data files, C extensions, namespace packages, and versioning, alongside instructions for publishing to repositories like PyPI.

What it does

  • Defines project directory structures using source or flat layouts
  • Configures build systems and metadata using pyproject.toml
  • Manages dependencies and optional development environments
  • Implements versioning strategies including semantic and git-based versioning
  • Provides patterns for CLI entry points and C extensions
  • Guides the process of building and testing installable distribution packages

When to use it

  • When you need to turn a Python project into an installable library
  • When building command-line tools that require entry points
  • When preparing a Python project for distribution on PyPI or private repositories
  • When standardizing project configuration across multiple Python modules

Advantages

  • Adheres to modern Python packaging standards (PEP 517/518/621)
  • Supports flexible project layouts for better code isolation
  • Centralizes project configuration in a single pyproject.toml file
  • Includes patterns for complex requirements like C extensions and data files

Usage examples

“How do I set up a new Python project for distribution?”
The agent provides a recommended source-layout structure and a template for the pyproject.toml file to define project metadata and dependencies.
“How can I include non-Python data files in my package?”
The agent explains how to use the tool.setuptools.package-data configuration in pyproject.toml and how to access those files using importlib.resources.
“How do I add a CLI command to my Python package?”
The agent shows how to define entry points in the project.scripts section of pyproject.toml to map commands to specific functions.
“How do I manage versions using Git tags?”
The agent demonstrates the use of setuptools-scm to automatically derive package versions from Git tags and commits.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/wshobson/python-packaging/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip python-packaging.zip -d .agents/skills

Documentation by Seth Hobson

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 = "[email protected]"}]
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

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.

Files

references/advanced-patterns.md

Python Packaging — Advanced Reference

Advanced packaging patterns including data files, namespace packages, C extensions, version management, testing installation, documentation templates, and distribution workflows.

Pattern 11: Including Data Files

[tool.setuptools.package-data]
my_package = [
    "data/*.json",
    "templates/*.html",
    "static/css/*.css",
    "py.typed",
]

Accessing data files:

# src/my_package/loader.py
from importlib.resources import files
import json

def load_config():
    """Load configuration from package data."""
    config_file = files("my_package").joinpath("data/config.json")
    with config_file.open() as f:
        return json.load(f)

# Python 3.9+
from importlib.resources import files

data = files("my_package").joinpath("data/file.txt").read_text()

Pattern 12: Namespace Packages

For large projects split across multiple repositories:

# Package 1: company-core
company/
└── core/
    ├── __init__.py
    └── models.py

# Package 2: company-api
company/
└── api/
    ├── __init__.py
    └── routes.py

Do NOT include init.py in the namespace directory (company/):

# company-core/pyproject.toml
[project]
name = "company-core"

[tool.setuptools.packages.find]
where = ["."]
include = ["company.core*"]

# company-api/pyproject.toml
[project]
name = "company-api"

[tool.setuptools.packages.find]
where = ["."]
include = ["company.api*"]

Usage:

# Both packages can be imported under same namespace
from company.core import models
from company.api import routes

Pattern 13: C Extensions

[build-system]
requires = ["setuptools>=61.0", "wheel", "Cython>=0.29"]
build-backend = "setuptools.build_meta"

[tool.setuptools]
ext-modules = [
    {name = "my_package.fast_module", sources = ["src/fast_module.c"]},
]

Or with setup.py:

# setup.py
from setuptools import setup, Extension

setup(
    ext_modules=[
        Extension(
            "my_package.fast_module",
            sources=["src/fast_module.c"],
            include_dirs=["src/include"],
        )
    ]
)

Version Management

Pattern 14: Semantic Versioning
# src/my_package/__init__.py
__version__ = "1.2.3"

# Semantic versioning: MAJOR.MINOR.PATCH
# MAJOR: Breaking changes
# MINOR: New features (backward compatible)
# PATCH: Bug fixes

Version constraints in dependencies:

dependencies = [
    "requests>=2.28.0,<3.0.0",  # Compatible range
    "click~=8.1.0",              # Compatible release (~= 8.1.0 means >=8.1.0,<8.2.0)
    "pydantic>=2.0",             # Minimum version
    "numpy==1.24.3",             # Exact version (avoid if possible)
]
Pattern 15: Git-Based Versioning
[build-system]
requires = ["setuptools>=61.0", "setuptools-scm>=8.0"]
build-backend = "setuptools.build_meta"

[project]
name = "my-package"
dynamic = ["version"]

[tool.setuptools_scm]
write_to = "src/my_package/_version.py"
version_scheme = "post-release"
local_scheme = "dirty-tag"

Creates versions like:

  • 1.0.0 (from git tag)

  • 1.0.1.dev3+g1234567 (3 commits after tag)

Testing Installation

Pattern 16: Editable Install
# Install in development mode
pip install -e .

# With optional dependencies
pip install -e ".[dev]"
pip install -e ".[dev,docs]"

# Now changes to source code are immediately reflected
Pattern 17: Testing in Isolated Environment
# Create virtual environment
python -m venv test-env
source test-env/bin/activate  # Linux/Mac
# test-env\Scripts\activate  # Windows

# Install package
pip install dist/my_package-1.0.0-py3-none-any.whl

# Test it works
python -c "import my_package; print(my_package.__version__)"

# Test CLI
my-tool --help

# Cleanup
deactivate
rm -rf test-env

Documentation

Pattern 18: README.md Template
# My Package

[![PyPI version](https://badge.fury.io/py/my-package.svg)](https://pypi.org/project/my-package/)
[![Python versions](https://img.shields.io/pypi/pyversions/my-package.svg)](https://pypi.org/project/my-package/)
[![Tests](https://github.com/username/my-package/workflows/Tests/badge.svg)](https://github.com/username/my-package/actions)

Brief description of your package.

## Installation

```bash
pip install my-package
```

## Quick Start

```python
from my_package import something

result = something.do_stuff()
```

## Features

- Feature 1
- Feature 2
- Feature 3

## Documentation

Full documentation: https://my-package.readthedocs.io

## Development

```bash
git clone https://github.com/username/my-package.git
cd my-package
pip install -e ".[dev]"
pytest
```

## License

MIT

Common Patterns

Pattern 19: Multi-Architecture Wheels
# .github/workflows/wheels.yml
name: Build wheels

on: [push, pull_request]

jobs:
  build_wheels:
    name: Build wheels on ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]

    steps:
      - uses: actions/checkout@v3

      - name: Build wheels
        uses: pypa/[email protected]

      - uses: actions/upload-artifact@v3
        with:
          path: ./wheelhouse/*.whl
Pattern 20: Private Package Index
# Install from private index
pip install my-package --index-url https://private.pypi.org/simple/

Or add it to pip.conf:

[global]
index-url = https://private.pypi.org/simple/

Do not pair a private index-url with extra-index-url = https://pypi.org/simple/. pip treats every index as equal and installs the highest version it finds, so anyone who publishes a package with one of your private names on PyPI can replace it (dependency confusion). If you also need public packages, let the private index proxy PyPI, or use a tool that pins each package to one index.

# Upload to private index
twine upload --repository-url https://private.pypi.org/ dist/*

File Templates

.gitignore for Python Packages
# Build artifacts
build/
dist/
*.egg-info/
*.egg
.eggs/

# Python
__pycache__/
*.py[cod]
*$py.class
*.so

# Virtual environments
venv/
env/
ENV/

# IDE
.vscode/
.idea/
*.swp

# Testing
.pytest_cache/
.coverage
htmlcov/

# Distribution
*.whl
*.tar.gz
MANIFEST.in
# MANIFEST.in
include README.md
include LICENSE
include pyproject.toml

recursive-include src/my_package/data *.json
recursive-include src/my_package/templates *.html
recursive-exclude * __pycache__
recursive-exclude * *.py[co]

Checklist for Publishing

  • [ ] Code is tested (pytest passing)

  • [ ] Documentation is complete (README, docstrings)

  • [ ] Version number updated

  • [ ] CHANGELOG.md updated

  • [ ] License file included

  • [ ] pyproject.toml is complete

  • [ ] Package builds without errors

  • [ ] Installation tested in clean environment

  • [ ] CLI tools work (if applicable)

  • [ ] PyPI metadata is correct (classifiers, keywords)

  • [ ] GitHub repository linked

  • [ ] Tested on TestPyPI first

  • [ ] Git tag created for release

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Seth Hobson
Publisher
Seth Hobson (Community)
Source
wshobson/agents · plugins/python-development/skills/python-packaging · commit 4bde316
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Seth Hobson.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download python-packaging.zip