MLflow tracking image blocked on Python 3.14: mlflow imports importlib.abc.Traversable, removed in 3.14

[IIchukissII]

#211 moved the services to Python 3.14. The MLflow tracking image is held at 3.11, because mlflow does not run on 3.14.

Not a packaging problem

mlflow is pure-python. It resolves cleanly on cp314 — the full 95-package closure installs with --only-binary=:all: and no complaint. No wheel check, lock regeneration, or dependency gate can see this. It is mlflow's own source:

# mlflow/assistant/skill_installer.py:11
from importlib.abc import Traversable

ImportError: cannot import name 'Traversable' from 'importlib.abc'

Python 3.14 removed importlib.abc.Traversable (deprecated since 3.12, where it moved to importlib.resources.abc). The import chain is reached on server start:

uvicorn -> mlflow.server.fastapi_app
        -> mlflow.server.assistant.api
        -> mlflow.assistant.skill_installer   <- dies here

So the tracking server cannot boot. The live tracking-gateway proof caught it immediately — it gates on a real MLflow write (#204), so the broken image failed loudly rather than shipping.

Only the server is affected

The mlflow client imports fine on 3.14 (verified on CPython 3.14.6):

	on Python 3.14
import mlflow (client)	OK
import mlflow.server.fastapi_app (server)	ImportError

That is why services/ml_service and services/notebook_tracking_gateway — both mlflow clients — already run on 3.14 with their suites green. Only infrastructure/mlflow stays behind.

The trigger

3.14.0 is the newest mlflow, and no release yet declares Python 3.14 support (no Programming Language :: Python :: 3.14 classifier on any 3.x release).

Lift when mlflow ships a release that runs on 3.14. Then it is:

• infrastructure/mlflow/Dockerfile: python:3.11-slim → python:3.14-slim
• regenerate infrastructure/mlflow/requirements.txt for cp314 — the command is in the file's header. Note it needs two platform tags (manylinux_2_28_x86_64 and manylinux2014_x86_64): the scientific wheels ship 2_28 for cp314 while psycopg2-binary still ships only manylinux2014, and either tag alone fails to resolve.
• psycopg2-binary 2.9.9 → 2.9.12 goes with it (2.9.9 publishes no cp314 wheel)
• remove the hold comment at the top of the Dockerfile
• the tracking-gateway integration proof must be green — it is the check that catches exactly this

Blocks the last image of Dependabot #182 (with the 2 notebook kernels in #220).

[IIchukissII]

Re-verified 2026-07-30 — still blocked. Not stale, do not close.

Checked at the source rather than by version number:

mlflow latest on PyPI  = 3.14.0   (unchanged)
mlflow-3.14.0-py3-none-any.whl
  mlflow/assistant/skill_installer.py:11
    from importlib.abc import Traversable

One occurrence, still there. The release number reading "3.14" is a coincidence, not a Python 3.14 fix — worth stating explicitly because it invites exactly the wrong conclusion.

Independently confirmed by CI today: dependabot proposed python:3.11-slim -> 3.14-slim for this image in the docker group, and the build failed before mlflow was even reached — psycopg2-binary has no cp314 wheel, so pip fell back to a source build and died on a missing pg_config. So the tracking image has two independent 3.14 blockers, not one.

The image stays pinned at 3.11. #260 added a dependabot ignore for python minors as well as majors, because a Python feature release arrives here as a semver minor and the major-only rule let this through.