Skip to content

fix: pin joserfc in requirements.txt to unblock deploy#704

Merged
jirhiker merged 1 commit into
stagingfrom
fix/requirements-add-joserfc
Jun 8, 2026
Merged

fix: pin joserfc in requirements.txt to unblock deploy#704
jirhiker merged 1 commit into
stagingfrom
fix/requirements-add-joserfc

Conversation

@jirhiker

@jirhiker jirhiker commented Jun 8, 2026

Copy link
Copy Markdown
Member

Why

  • Deploy buildpack fails:
    ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
    joserfc>=1.6.0 ... (from authlib==1.7.2->-r requirements.txt (line 225))
    
  • authlib 1.6.x → 1.7.2 added joserfc as a new runtime dependency. The lockfile bump updated uv.lock / pyproject.toml but requirements.txt was not regenerated, so joserfc was missing. pip then resolved it transitively as the unpinned joserfc>=1.6.0, which --require-hashes rejects.

How

  • Add joserfc==1.7.1 with its sdist + py3-none-any wheel hashes copied from uv.lock. Pure-python wheel → platform-independent, so both hashes are complete.
  • Verified joserfc is the only non-dev dependency present in uv.lock but missing from requirements.txt (all other gaps are dev-group deps excluded by --no-dev).

Notes

  • Surgical one-package insert rather than a full uv export regen (local uv 0.9.7 emits a different per-platform hash set than CI, which would churn ~1000 lines).
  • Production is currently broken by this — staging→production release will carry the fix; if production needs it sooner, cherry-pick to a hotfix/v* branch.

authlib 1.6.x → 1.7.2 added joserfc as a new runtime dependency, but
the lockfile bump did not regenerate requirements.txt, so joserfc was
absent. The Google buildpack installs with pip --require-hashes, which
rejected the unpinned `joserfc>=1.6.0` pulled transitively from
authlib:

  ERROR: In --require-hashes mode, all requirements must have their
  versions pinned with ==. These do not: joserfc>=1.6.0

Add joserfc==1.7.1 with its sdist + py3-none-any wheel hashes from
uv.lock. Verified joserfc is the only non-dev dependency in uv.lock
missing from requirements.txt.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings June 8, 2026 18:26

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot wasn't able to review any files in this pull request.

@jirhiker jirhiker merged commit 018cc44 into staging Jun 8, 2026
9 checks passed
@jirhiker jirhiker deleted the fix/requirements-add-joserfc branch June 8, 2026 18:29
jirhiker added a commit that referenced this pull request Jun 8, 2026
…y) (#705)

### Why
Deploy buildpack fails again — next unpinned transitive after the
joserfc fix
([#704](#704)):
```
ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
python-discovery>=1.4 (from virtualenv==21.4.2->-r requirements.txt (line 2393))
```
Root cause: `pre-commit` was listed in main `[project.dependencies]`, so
it (and its whole toolchain — virtualenv, identify, nodeenv, cfgv,
distlib, platformdirs) shipped to production. `virtualenv 21.x`
introduced the unpinned transitive `python-discovery>=1.4`, which pip
`--require-hashes` rejects.

### How
- Move `pre-commit` from `[project.dependencies]` → `[dependency-groups]
dev`. It's a dev-only tool, never imported by app code.
- `uv lock` + `uv export --no-dev` regenerate the lock and requirements.
- Result: pre-commit + entire chain (incl. virtualenv →
python-discovery) removed from the production requirement set.

### Verification
- Every non-dev package in `uv.lock` is still pinned + hashed in
`requirements.txt`; only dev-group deps are absent.
- Confirmed the linux `cp313` x86_64 wheels the buildpack installs are
present (checked yarl).
- `uv lock --check` passes.

### Notes
- Large `requirements.txt` churn: besides removing the pre-commit chain,
local `uv 0.9.7` emits only the py3.13-relevant wheel hashes (lock
`requires-python >=3.13`) vs the old broader set. Functionally complete
for the deploy target; CD regenerates with the same `uv export --no-dev`
anyway.
- `uv.lock` `revision` bumped 2 → 3 by uv; CD uses `setup-uv` latest
(forward-compatible).
- Unblocks the release build on
[#695](#695)
once merged to staging.

---------

Co-authored-by: Claude Opus 4.7 <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.

2 participants