Skip to content

Derive package version from git tags via hatch-vcs - #6

Merged
JSv4 merged 4 commits into
mainfrom
chore/tag-derived-versioning
Jul 7, 2026
Merged

Derive package version from git tags via hatch-vcs#6
JSv4 merged 4 commits into
mainfrom
chore/tag-derived-versioning

Conversation

@JSv4

@JSv4 JSv4 commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Description of the change

Fixes PyPI publishing: pyproject.toml was never bumped past 1.0.2, so the v2.0.0 and v2.0.1 release workflows both rebuilt 1.0.2 and were rejected by PyPI (both runs failed; PyPI is stuck at 1.0.2).

1. Tag-derived versioning (hatchling + hatch-vcs). The package version is derived from the release tag (v2.0.12.0.1). Cutting a release now only requires pushing a tag — there is no version string left anywhere in the repo.

  • Why not uv_build: it rejects dynamic = ["version"] outright (missing field 'version') — dynamic/VCS metadata is deliberately unsupported. uv remains the frontend everywhere (uv sync/lock/build unchanged; lockfile now records the root project version as (dynamic)).
  • The publish workflow checks out full history (fetch-depth: 0) so git describe can see tags.
  • The sdist is restricted to the package itself — tests/fixtures is ~90MB and was at risk of being shipped by hatchling's defaults.

2. Drop the benchmark-only [tables] extra from published metadata. It existed solely to reproduce the pymupdf4llm table ablation; the shipped package never imports those deps (the native table engine is default and self-contained), and an AGPL ablation dependency has no business in PyPI metadata.

3. Remove the pymupdf4llm ablation code entirely (per review): the delegation path in table_providers.py, the spike-script engine mode, and the Fast-vs-Quality timing script. The native table engine already ties the external parser it was compared against. The pymupdf4llm baseline pipeline (rival parser in the leaderboard field run) is unaffected.

Verification

  • uv build at an untagged commit → 2.0.2.dev0+g6884782a1 (correct setuptools-scm derivation); wheel-from-sdist path (no .git) resolves via PKG-INFO
  • wheel carries all 41 tracked package .py files; sdist has no tests/fixtures
  • uvx twine check dist/* PASSED for both artifacts
  • uv sync --frozen works (Docker parity; images copy .git and the python:3.14-bookworm base has git)
  • pytest tests/test_package_metadata.py tests/test_service.py tests/test_table_engine.py — 76 passed
  • get_table_provider() default remains the native engine; WARP_TABLE_PROVIDER=pymupdf4llm now maps to no provider (warp's raw tables)

Type of change

  • Bug fix (non-breaking change that fixes an issue)

🤖 Generated with Claude Code

JSv4 and others added 4 commits July 7, 2026 06:46
The version in pyproject.toml was never bumped past 1.0.2, so the v2.0.0
and v2.0.1 release publishes both rebuilt 1.0.2 and were rejected by
PyPI. Switch the build backend to hatchling + hatch-vcs so the version
is derived from the release tag (v2.0.1 -> 2.0.1) and a release only
requires pushing a tag; there is no version string left in the repo.

- uv remains the frontend (sync/lock/build); uv_build rejects
  dynamic = ["version"], which is why the backend changes
- publish workflow checks out full history so git describe sees tags
- sdist is restricted to the package (tests/fixtures is ~90MB)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The [tables] extra existed solely to reproduce the pymupdf4llm table
ablation in benchmarks/parsebench/RESULTS.md; the shipped package never
imports those dependencies (the native table engine is the default and
self-contained), and publishing an AGPL-licensed ablation dependency as
a package extra invites accidental installs. The benchmark provider
already degrades gracefully when the packages are absent; reproducing
the ablation is a plain `pip install pymupdf4llm markdown2`.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Follow-through on dropping the [tables] extra: delete the ablation code
itself, not just its published dependency. The pymupdf4llm delegation
path in table_providers.py, the pymupdf4llm engine mode in
tbl_engine_spike.py, and the Fast-vs-Quality timing script existed only
to compare against the external parser the native table engine already
ties; an unknown WARP_TABLE_PROVIDER value now simply disables the
provider. The pymupdf4llm *baseline pipeline* (a rival parser in the
leaderboard field run) is unaffected.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Python 3.14 changed the Linux multiprocessing default from fork to
forkserver; ParseBench's evaluation workers then no longer inherit the
in-process warp pipeline/adapter registrations, every layout example
fails with "no provider adapter matched", and Visual Grounding silently
collapses to ~10 while the run exits 0.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@JSv4
JSv4 merged commit 06ff6ca into main Jul 7, 2026
10 checks passed
JSv4 added a commit that referenced this pull request Jul 7, 2026
Full official faithful run from the v2.0.1 merge commit (native table
engine, OCR extra installed, VG scored in-run via the fork fix):
Tables 57.45 / Charts 7.04 / Content 70.81 / Sem.Format 45.81 /
Visual 20.71 -> Overall 40.36 (+1.39 vs the 2026-07-02 baseline, from
PR #5's content-faithfulness root fixes). A back-to-back rerun after
PR #6's ablation removal reproduced every dimension to within 0.04,
confirming the removal is score-neutral. Also corrects the stale claim
that the 42 image-only layout failures pad the VG headline (padding is
product-type-scoped and never reaches avg_layout_element_rule_pass_rate).

User-authorized direct push to main (docs-only change).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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