Make renderers optional and add PyPI publish workflow

[willccbb]

Motivation

• Avoid installing the local packages/renderers package by default so consumers only opt in when they need rendering support.
• Provide a standard, automated PyPI release flow for the renderers package so it can be published independently from the root package.

Description

• Remove "renderers" from the root dependencies list in pyproject.toml and add an optional extra renderers = ["renderers"] under [project.optional-dependencies] so users can pip install verifiers[renderers] to opt in.
• Keep the local editable source reference in tool.uv.sources pointing at packages/renderers so the package remains available for local development.
• Add a new GitHub Actions workflow .github/workflows/publish-renderers.yml that validates renderers-v* tags, checks the tag against packages/renderers/pyproject.toml, builds with uv build packages/renderers, and publishes with uv publish --token "$PYPI_TOKEN" packages/renderers/dist/*.

Testing

• Ran uv run pre-commit install and the install completed successfully.
• Verified pyproject.toml can be parsed with python - <<'PY' import tomllib; tomllib.load(open('pyproject.toml','rb')) which returned successfully.
• Ran uv run pre-commit run --all-files and all configured checks passed.

---

Codex Task

---

Note

Medium Risk
Medium risk because it changes dependency packaging/import behavior and adds a new automated PyPI release workflow; issues would mainly surface as install/import failures or mis-published renderer releases.

Overview
Adds a new GitHub Actions workflow to publish the renderers package to PyPI on renderers-v* tags (or manual dispatch), including a tag-to-packages/renderers/pyproject.toml version check and uv build/publish steps.

Makes renderers an opt-in dependency: removes it from core install, introduces the renderers extra (verifiers[renderers]), and switches RendererClient to lazy-import with clearer install guidance/errors when the extra isn’t present. Docs are updated to instruct installing the extra before using client_type="renderer".

Bumps packages/renderers to 0.1.5, adds runtime deps (openai, tiktoken, jinja2, numpy) and dev deps (pytest, pytest-asyncio), and updates lockfiles to reflect publishing/consuming renderers from PyPI rather than a local editable source.

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

[willccbb]

@cursoragent change PYPI_TOKEN -> PYPI_RENDERERS_TOKEN

[cursor]

Taking a look!

  

[willccbb]

@cursoragent use pypi version as source for renderers, not local package

[cursor]

• Switched renderers to resolve from PyPI by removing the local override in pyproject.toml ([tool.uv.sources] renderers = { path = "packages/renderers", editable = true } removed). The optional extra renderers = ["renderers"] remains, so uv add verifiers[renderers] pulls from PyPI.

• Left workflows and code that build/publish the local packages/renderers for releases unchanged; this only affects how the root project depends on renderers.

• Committed and pushed to codex/make-renderers-package-optional-dependency. The PR now reflects this change.

  

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 7ebf026. Configure here.}

[eligotts]

what in the codex is this?

[willccbb]

@cursoragent whats going on here

[cursor]

It’s from uv’s cross-environment lock. uv locks against a matrix of Python versions and platforms (e.g., win32, emscripten, and “everything else”), then encodes per-environment dependency rules as boolean “markers.” That odd-looking marker on torch is uv’s normalized way of saying “install torch everywhere except on unsupported combos (notably emscripten and sometimes Windows with newer Python).” It isn’t hand-authored code; it’s machine-generated metadata uv uses to decide what to install per environment.

For context, you can see the matrix uv baked into the lock:

resolution-markers = [
    "python_full_version >= '3.13' and sys_platform == 'win32'",
    "python_full_version == '3.12.*' and sys_platform == 'win32'",
    "python_full_version >= '3.13' and sys_platform == 'emscripten'",
    "python_full_version == '3.12.*' and sys_platform == 'emscripten'",
    "python_full_version >= '3.13' and sys_platform != 'emscripten' and sys_platform != 'win32'",
    "python_full_version == '3.12.*' and sys_platform != 'emscripten' and sys_platform != 'win32'",
    "python_full_version == '3.11.*' and sys_platform == 'win32'",
    "python_full_version == '3.11.*' and sys_platform == 'emscripten'",
    "python_full_version == '3.11.*' and sys_platform != 'emscripten' and sys_platform != 'win32'",
    "python_full_version < '3.11'",
]

If you want to avoid this cross-platform noise, I can regenerate the lock targeted only to our supported environment (e.g., Linux + CPython 3.13) so these multi-OS markers disappear.

  

[willccbb]

codex says it's fine / expected

[willccbb]

Yes, that marker is normal in uv.lock.

It’s not from our pyproject.toml, and we didn’t hand-edit it. In this branch the lockfiles are clean, and that marker appears on upstream dependency edges for packages like mlx-lm and xformers.

It simplifies to:

• On normal Linux/macOS: install numpy
• On Windows or Emscripten: install only for Python <3.11

So for our supported CI/dev targets, it effectively means “yes, numpy”. It’s just uv preserving upstream platform/Python markers in the universal lockfile.