Publish palace-util and palace-opds to PyPI on release (PP-4076)

[jonathangreen]

Description

Two things:

1. Dynamic versioning for both workspace packages. Each package's pyproject.toml now declares dynamic = ["version"] and sources the version from a committed _version.py stub via hatchling's built-in regex version source — no plugins. The stub carries a dev placeholder (0.0.0.dev0, __commit__ = None, __branch__ = None) so uv build --package … works out-of-box for local and CI builds without an explicit version override. The release workflow overwrites _version.py with real dunamai-computed values right before uv build, so the wheel metadata picks up the real version.

2. publish-pypi.yml workflow triggered by published GitHub Releases. Matrix-builds both packages in parallel, uses PyPI's Trusted Publishing (OIDC) flow — no API tokens stored in the repo or in GitHub secrets. The workflow also pins the intra-workspace dep: uv build leaves workspace deps as bare palace-util in Requires-Dist, which would fail to resolve on PyPI, so the workflow seds in palace-util==<version> before building palace-opds.

Motivation and Context

With palace-util and palace-opds extracted as standalone packages, they should be installable from PyPI so downstream Palace services (and the wider OPDS-consuming community for palace-opds) can depend on them without pulling in the palace-manager monorepo. palace-manager itself is intentionally NOT published here — it needs additional work first (alembic and friends prevent a clean wheel build).

One-time PyPI setup

For each of the two projects (do once per project):

1. Reserve the name on PyPI (manual first upload or admin assistance).
2. In the PyPI project's Publishing settings, add a trusted publisher:
   • Owner: ThePalaceProject
   • Repository: circulation
   • Workflow filename: publish-pypi.yml
   • Environment name: pypi
3. (Optional) Create the pypi environment in the repo's Settings → Environments and add an approval gate / branch restriction for an extra guard.

After that, publishing a GitHub Release with a tag that dunamai can parse as semver (e.g. v1.0.0) will automatically upload both wheels.

How Has This Been Tested?

• Local uv build --package palace-util produces palace_util-0.0.0.dev0-py3-none-any.whl.
• Local uv build --package palace-opds produces palace_opds-0.0.0.dev0-py3-none-any.whl.
• Simulated CI flow (overwrote _version.py with __version__ = "1.2.3", then rebuilt) — wheel correctly tagged palace_util-1.2.3-py3-none-any.whl. Reverted the stub afterward.
• Runtime: python -c "import palace.util; print(palace.util.__version__)" → 0.0.0.dev0.
• Runtime: python -c "import palace.opds; print(palace.opds.__version__)" → 0.0.0.dev0.
• mypy passes (1128 source files).
• pytest tests/palace_util tests/palace_opds — 232 tests pass.

First real end-to-end verification happens on the first tagged release after this lands.

Checklist

• I have updated the documentation accordingly.
• All new and existing tests passed.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.30%. Comparing base (11171c1) to head (8d9177c).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3238   +/-   ##
=======================================
  Coverage   93.30%   93.30%           
=======================================
  Files         498      502    +4     
  Lines       46147    46157   +10     
  Branches     6318     6318           
=======================================
+ Hits        43059    43069   +10     
  Misses       2003     2003           
  Partials     1085     1085           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.