If in doubt, delete the uv.lock file
- ID
- 41843
- Status
- summarized
- Published
- 02 Nov 2026, 7:24 AM
- Fetched
- 02 Nov 2026, 7:49 AM
- Provider
- Simon Willison
- Category
- developer-ai
- Original URL
- https://simonwillison.net/2026/Nov/1/delete-uv-lock-first/
- Source URL
- https://simonwillison.net/atom/everything/
Summary
- Score
- 5.5
- Created
- 02 Nov 2026, 7:49 AM
- Tags
- Audience
- developersai_ml_learnersvibe_coders
What happened
Simon Willison's short note describes hitting build failures after moving to Python 3.15, with the concrete example of `watchfiles==1.1.1` failing because `maturin.build_wheel` reported that "the configured Python interpreter version (3.15) is newer than PyO3's maximum supported version (3.14)". The fix he keeps reaching for: delete the stray `uv.lock` (left behind by `uv run pytest`, gitignored, never committed for his library projects) and re-run. He notes libraries generally shouldn't ship a `uv.lock` at all, since locking versions for downstream users is rude.
Why it matters
If you're on Python 3.15 and a `uv run` command dies with a PyO3/maturin "maximum supported version (3.14)" error, the cause is probably a stale local `uv.lock` pinning an older dependency rather than your code — delete it and re-run before you start downgrading Python or hand-editing pins. For anyone maintaining a library, this is also a reminder to keep `uv.lock` in `.gitignore` so it never gets committed and shipped to consumers.
Discussion angle
Has anyone else hit Python 3.15 wheel gaps in native-extension packages (watchfiles, PyO3-based tools)? Worth comparing notes on whether you delete the lockfile, pin the interpreter to 3.14, or wait for upstream wheels — and whether your team commits `uv.lock` for apps but not libraries.