From hep-python-tools
Use when creating a new Python package, adding pyproject.toml to an existing project, choosing a build backend, setting up src layout, configuring VCS-based versioning, or managing a development environment with pixi or uv for a HEP Python project.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hep-python-tools:python-packagingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Modern Python packages declare all metadata in `pyproject.toml` and use a
Modern Python packages declare all metadata in pyproject.toml and use a
dedicated build backend (hatchling, flit, uv_build, etc.). The src layout
(src/<package>/) is the community standard. Environment management for HEP
projects should use pixi (preferred) or uv.
The Scientific Python community maintains a template ( scientific-python/cookie) and checker (sp-repo-review) that encode these recommendations. Use them as a reference for new projects.
setup.py / setup.cfg project to pyproject.tomlpixi.toml for reproducible developer environments| Concept | Details |
|---|---|
pyproject.toml | Single config file; replaces setup.py, setup.cfg, MANIFEST.in |
| Build backend | Hatchling is recommended; flit-core and uv_build also work well |
| src layout | src/<package>/ prevents accidental local-import bugs |
requires-python | Set minimum; never set an upper cap |
| VCS versioning | hatch-vcs reads git tags; no manual version bumps |
| pixi | Preferred for lockfile-based reproducible environments |
[project])[project]
name = "my-hep-tool"
description = "Short description"
readme = "README.md"
license = "MIT"
requires-python = ">=3.11"
dynamic = ["version"]
dependencies = [
"awkward>=2",
"uproot>=5",
"hist>=2.7",
]
[project.optional-dependencies]
dev = ["pytest", "pytest-cov"]
dynamic = ["version"] lets the backend compute the version; omit it only if
you pin the version manually.
my-hep-tool/
pyproject.toml
pixi.toml # or uv.lock / environment.yaml
src/
my_hep_tool/
__init__.py
analysis.py
tests/
test_analysis.py
[build-system]
requires = ["hatchling", "hatch-vcs"]
build-backend = "hatchling.build"
[tool.hatch.version]
source = "vcs"
Add these two files so git archive (GitHub downloads) also get the version:
.git_archival.txt:
node: $Format:%H$
node-date: $Format:%cI$
describe-name: $Format:%(describe:tags=true,match=*[0-9]*)$
.gitattributes (append):
.git_archival.txt export-subst
# pixi.toml
[project]
name = "my-hep-tool"
channels = ["conda-forge"]
platforms = ["linux-64", "osx-arm64"]
[dependencies]
python = ">=3.11"
awkward = ">=2"
uproot = ">=5"
hist = ">=2.7"
[feature.dev.dependencies]
pytest = "*"
pre-commit = "*"
[feature.dev.tasks]
test = "pytest"
pre-commit = "pre-commit run --all-files"
[environments]
dev = { features = ["dev"], solve-group = "default" }
# In pyproject.toml, uv_build backend
[build-system]
requires = ["uv_build>=0.7.19"]
build-backend = "uv_build"
Run with uv run pytest or uv sync --group dev.
setup.py or setup.cfg for new projects — those are
setuptools-specific legacy files. Modern backends don't use them.requires-python: >=3.11 is correct; >=3.11,<4 is not
— upper caps break installation for future Python versions.import my_hep_tool silently picks up the
un-installed tree.license.file set explicitly in [project]; hatchling and
uv_build detect it automatically.dynamic = ["version"] must be set when using hatch-vcs; otherwise
hatchling expects a static version string.npx claudepluginhub usatlas/marketplace --plugin hep-python-toolsGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.