Skip to content

[META]: Generate package metadata dynamically for PyPI#95

Open
spencrr wants to merge 3 commits into
microsoft:mainfrom
spencrr:dev/spencrr/dynamic-readme-image-permalink-and-version
Open

[META]: Generate package metadata dynamically for PyPI#95
spencrr wants to merge 3 commits into
microsoft:mainfrom
spencrr:dev/spencrr/dynamic-readme-image-permalink-and-version

Conversation

@spencrr

@spencrr spencrr commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

Description

Move RAMPART package metadata generation to Hatchling so release artifacts can produce PyPI-safe metadata without requiring manual README or version edits.

Dynamic README metadata

The source README.md now keeps repository image links relative, while package builds generate PyPI README metadata with raw GitHub image URLs. This keeps the README readable in GitHub and makes images render reliably on PyPI. The build-time README generation uses Hatch’s dynamic metadata hook pattern (Hatch dynamic metadata, custom metadata hooks).

Dynamic version metadata

Package versions are now derived from Git tags through Hatch VCS instead of a static project.version field. Release builds get their version from tags like vX.Y.Z; development builds after a tag infer a development version. Local version suffixes such as +g<sha> are omitted for public-package compatibility via local_scheme = "no-local-version" (hatch-vcs version source, setuptools-scm local schemes).

The release process docs were updated to describe tag-derived versions, relative README image links, and the requirement that release tags be reachable from main history for expected development-version inference.

Package data inclusion

The setuptools-specific prompt inclusion configuration was removed as part of the Hatchling migration:

[tool.setuptools.package-data]
rampart = [
    "drivers/prompts/*.yaml",
    "evaluators/prompts/*.yaml",
]

Hatchling does not use tool.setuptools.package-data. Instead, it uses Hatch’s file-selection model. With:

[tool.hatch.build.targets.wheel]
packages = ["rampart"]

the wheel target explicitly selects the rampart/ package directory. Hatch documents packages as semantically equivalent to only-include, with package paths rewritten as needed. Selected directories are traversed by default, subject to normal VCS ignore and exclude behavior.

I verified the built wheel directly and confirmed the prompt YAML files are still present:

rampart/drivers/prompts/llm_driver_system_prompt.yaml
rampart/evaluators/prompts/llm_judge.yaml

This preserves the previous package data behavior while removing configuration that only applied to the old setuptools backend. References: Hatch file selection, Hatch packages, and wheel default file selection.

Breaking changes

None. This changes package build metadata generation only; runtime APIs and package contents are unchanged.

Checklist

  • pre-commit run --all-files passes
  • Tests added or updated for changes - existing unit tests cover runtime behavior; package build and wheel metadata inspection verify the packaging changes.
  • Documentation updated - release process docs now cover dynamic versioning and README metadata behavior.

Verification

  • uv lock --check: passes
  • uv run ruff check scripts/hatch_build.py: passes
  • uv run --with build python -m build: passes
  • uv run pytest tests/unit -q: 489 passed
  • Wheel metadata inspection:
    • Generated by Hatchling
    • Version inferred dynamically without a local +g<sha> suffix, instead .dev{commits_since_tag}
    • README image path rewritten from relative source path to a raw GitHub URL

@spencrr spencrr requested a review from a team June 22, 2026 21:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant