Adopt verifiers-style dynamic versioning

[hallerite]

Why

Today, .github/workflows/publish-dev.yml creates a fresh renderers-v<next>.dev<N> tag on every push to main and builds from that tag. This works for the publish path but breaks local development: setuptools-scm refuses to bump a pre-existing .devN tag, so on any untagged main commit, uv lock / uv build fails with:

ValueError: Error getting the version from source `vcs`:
choosing custom numbers for the `.devX` distance is not supported.
The 0.1.8.dev45 can't be bumped

Forcing every contributor through SETUPTOOLS_SCM_PRETEND_VERSION=... to run uv lock isn't a great state. It also pollutes the tag namespace (~45 dev tags per release cycle).

verifiers (sibling repo, same maintainers) solves the same PyPI +gHASH-local-segment constraint differently — and we should match.

What changes

pyproject.toml

Add [tool.hatch.version.raw-options]:

[tool.hatch.version.raw-options]
local_scheme = "no-local-version"
git_describe_command = [
    "git", "describe", "--tags", "--long",
    "--match", "renderers-v[0-9]*.[0-9]*.[0-9]*",
    "--exclude", "*dev*",
]

• local_scheme = "no-local-version" strips the +gHASH segment at build time. PyPI accepts the wheel directly with no pre-created tag at HEAD.
• git_describe_command restricts version resolution to stable renderers-v<MAJOR>.<MINOR>.<PATCH> tags via --match + --exclude "*dev*". setuptools-scm derives the dev version from commit distance to the last stable tag (e.g. 0.1.8.dev49); no pre-created tag needed.

.github/workflows/publish-dev.yml

Drop the tag: job entirely (73 lines → ~30 less). The build: job now checks out main with fetch-depth: 0 and runs uv build — hatch-vcs computes the version on the fly. Same publish cadence (every push → dev wheel on PyPI), no per-commit tags created.

Existing dev tags

The ~45 renderers-v0.1.8.devN tags on the remote stay where they are; --exclude "*dev*" filters them out of git describe so they don't interfere with version resolution. Cleaning them up is optional housekeeping for a separate PR.

Verification (locally)

$ uv build               # no env vars
Successfully built dist/renderers-0.1.8.dev49.tar.gz
Successfully built dist/renderers-0.1.8.dev49-py3-none-any.whl

$ uv lock                # no env vars
Resolved 91 packages in 654ms

Stats

 .github/workflows/publish-dev.yml | 73 ++++++++++-----------------------------
 pyproject.toml                    | 16 +++++++++
 uv.lock                           |  4 +--
 3 files changed, 36 insertions(+), 57 deletions(-)

Net −21 lines (excluding the uv.lock cutoff-date refresh and an unrelated openai-harmony constraint drift fix — see below).

uv.lock side effects

Two benign changes from re-running uv lock:

• exclude-newer cutoff advances 2026-05-18 → 2026-06-19 (rolling 7-day cooldown catching up).
• openai-harmony constraint in the lock realigns with pyproject.toml's stated >=0.0.4 (lock had drifted to >=0.0.8). pyproject.toml itself is unchanged — this is the lock catching up to a long-standing source constraint.

Outcome

• uv lock / uv build work on any main checkout without env-var workarounds.
• Same PyPI publish cadence (every main push → dev wheel).
• Aligned with verifiers / sibling PrimeIntellect-ai projects.
• ~45 fewer dev tags created per release cycle going forward.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes release versioning and PyPI publish behavior; mistakes could produce wrong wheel versions or duplicate-publish edge cases, though skip-existing mitigates retries.

Overview
Dev PyPI publishing no longer creates a renderers-v*.devN tag on every main push. The workflow builds directly from main with full git history; hatch-vcs derives PEP 440 dev versions from distance to the latest stable renderers-v* tag at build time.

pyproject.toml adds [tool.hatch.version.raw-options]: local_scheme = "no-local-version" (PyPI-friendly wheels without +gHASH) and a custom git_describe_command that only considers stable release tags and excludes legacy *dev* tags—fixing local uv lock / uv build failures when .devN tags already exist.

The publish step sets skip-existing: true on the PyPI action. uv.lock refreshes the rolling exclude-newer cutoff and realigns openai-harmony with >=0.0.4.

^{Reviewed by Cursor Bugbot for commit 35d51a9. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Adopt dynamic versioning from git tags in the dev publish workflow

• Removes the tag job from publish-dev.yml that created synthetic per-commit dev tags; the build job now checks out the full git history from the branch head and derives the version via hatch-vcs.
• Configures hatch-vcs in pyproject.toml with local_scheme = "no-local-version" and a git describe command scoped to stable renderers-v* tags, producing clean PEP 440 dev versions (e.g. 1.2.3.dev4) without a +gHASH local segment.
• Adds skip-existing: true to the PyPI publish step to avoid failures when the derived version already exists.
• Behavioral Change: versions are now derived from distance to the latest stable tag rather than a synthetic per-commit tag; legacy .devN tags are excluded from version resolution.

^{Macroscope summarized 35d51a9.}

[macroscopeapp]

Approvability

Verdict: Approved

This PR simplifies CI/CD versioning by replacing per-commit tag creation with hatch-vcs dynamic version derivation from git describe. Changes are limited to build configuration (pyproject.toml, workflow, lock file) with no runtime code impact.

^{You can customize Macroscope's approvability policy. Learn more.}