deps: bump mpmath from 1.3.0 to 1.4.1 - #332
Conversation
dependabot
Bot
added
dependencies
dc8cdad to
8a7ddbc
Compare
…migration Two follow-ups the CI run on PR #331 caught immediately, both fixed at the source rather than baselined/skipped: - tests_py/infrastructure/test_stdio_late_response.py's test method exceeded the 40-line/method cap after the first extraction pass (the extracted helper itself was still over). Split further: a _RaceFixtures dataclass + _build_race_fixtures() groups the six-value setup into one call, leaving _drive_late_request_scenario() and the test method both under the cap. - pyproject.toml gained exceptiongroup>=1.2.0 in a later edit than the `uv lock` run in the prior commit — CI's `uv lock --check` correctly caught the resulting drift. Re-locked (uv.lock unchanged in content, since exceptiongroup was already pinned transitively at the same version — only the marker condition and provenance changed) and regenerated the 5 requirements/*.txt files whose extras include the dev group. Also adds .craftsmanship.conf (same fix as PR #332/#416, not yet on this branch since it was cut before those merged): the local zetetic-marketplace pre-commit hook has no auto-generated-file detection and flags requirements/*.txt against the generic §4.1 500-line cap. Scoped skip for requirements/, matching the documented auto-generated exception. Distinct from this repo's own CI gate (scripts/check_craftsmanship.py), unaffected by this file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
ZETETIC-REVIEW: REQUEST_CHANGES Reviewed at head Move 0 — ledger / seen-defect checkNo unmapped paths, no un-issued "pre-existing/unrelated/out of scope" dismissals in the diff or commit message. Passes. StakesMedium-High: touches 13 install sites (CI workflows, composite action, 3 Dockerfiles, ClusterFuzzLite) and a dependency-resolution override that changes what 1. Is the
|
Review finding on PR #332: the prior comment called sympy 1.14.0's `mpmath<1.4` bound precautionary, on the strength of one working import+evalf call. The sympy maintainer's own issue tracker (sympy/sympy#29231) says otherwise: sympy 1.14.0 has a real, active dependency on a deprecated mpmath API (`mpf_log`), and an mpmath 1.4.0 ALPHA once broke `import sympy` outright before that got fixed. A sample of one code path working is not proof of general compatibility across sympy's much larger surface -- routing around a maintainer's bound requires knowing what it protects, not just testing that it doesn't (yet) bite the one call site checked. The practical decision is unchanged: this repo never imports sympy or mpmath directly (both arrive transitively through torch), so the deprecated-API surface sympy still touches is never exercised here, and the override remains safe to take. But it needed a ceiling: `override-dependencies = ["mpmath>=1.4.1"]` had no upper bound, so a routine `uv lock --upgrade` (not `--upgrade-package mpmath`) could pull a version sympy's own maintainer has already flagged as unsupported -- they state the next sympy release (1.15) will cap at `mpmath<1.5` specifically because of the alpha-0 breakage. Matched that ceiling: `mpmath>=1.4.1,<1.5`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
ZETETIC-REVIEW: APPROVE SummarySecond-round review of Verification performed this round (all against primary sources, no benchmark/test run)
Rules compliance (coding-standards.md)
StakesMedium — CI/build infrastructure and a resolver override affecting every install path in the repo (not High: no auth/billing/crypto/schema/concurrency surface). Full Move 1/3/6-equivalent care applied via source verification, matching the CORRECTION → verify-before-accept escalation this round required. IssuesBlockingNone. Non-blockingNone — the round-1 finding (unbounded override + unverified "precautionary" characterization) is fully resolved and independently confirmed against the primary source, not just re-asserted. VerdictAPPROVE. |
Review finding on PR #332: the prior comment called sympy 1.14.0's `mpmath<1.4` bound precautionary, on the strength of one working import+evalf call. The sympy maintainer's own issue tracker (sympy/sympy#29231) says otherwise: sympy 1.14.0 has a real, active dependency on a deprecated mpmath API (`mpf_log`), and an mpmath 1.4.0 ALPHA once broke `import sympy` outright before that got fixed. A sample of one code path working is not proof of general compatibility across sympy's much larger surface -- routing around a maintainer's bound requires knowing what it protects, not just testing that it doesn't (yet) bite the one call site checked. The practical decision is unchanged: this repo never imports sympy or mpmath directly (both arrive transitively through torch), so the deprecated-API surface sympy still touches is never exercised here, and the override remains safe to take. But it needed a ceiling: `override-dependencies = ["mpmath>=1.4.1"]` had no upper bound, so a routine `uv lock --upgrade` (not `--upgrade-package mpmath`) could pull a version sympy's own maintainer has already flagged as unsupported -- they state the next sympy release (1.15) will cap at `mpmath<1.5` specifically because of the alpha-0 breakage. Matched that ceiling: `mpmath>=1.4.1,<1.5`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
dec4dec to
56bae9e
Compare
|
ZETETIC-REVIEW: APPROVE Scope of this roundThe head this reviews is 1. What did the rewrite carry forward, intact?
Checked in the actual checked-out worktree at 2. What did the rewrite reintroduce or drop?
3. Do the hash pins still hold?mpmath 1.4.1's two hashes ( 4. Business gate
VerdictThe rewrite lost nothing and reintroduced nothing. |
…migration Two follow-ups the CI run on PR #331 caught immediately, both fixed at the source rather than baselined/skipped: - tests_py/infrastructure/test_stdio_late_response.py's test method exceeded the 40-line/method cap after the first extraction pass (the extracted helper itself was still over). Split further: a _RaceFixtures dataclass + _build_race_fixtures() groups the six-value setup into one call, leaving _drive_late_request_scenario() and the test method both under the cap. - pyproject.toml gained exceptiongroup>=1.2.0 in a later edit than the `uv lock` run in the prior commit — CI's `uv lock --check` correctly caught the resulting drift. Re-locked (uv.lock unchanged in content, since exceptiongroup was already pinned transitively at the same version — only the marker condition and provenance changed) and regenerated the 5 requirements/*.txt files whose extras include the dev group. Also adds .craftsmanship.conf (same fix as PR #332/#416, not yet on this branch since it was cut before those merged): the local zetetic-marketplace pre-commit hook has no auto-generated-file detection and flags requirements/*.txt against the generic §4.1 500-line cap. Scoped skip for requirements/, matching the documented auto-generated exception. Distinct from this repo's own CI gate (scripts/check_craftsmanship.py), unaffected by this file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat(mcp2): migrate off fastmcp onto the native mcp 2.0.0 SDK server mcp 2.0.0 folds FastMCP's decorator API directly into the SDK (mcp.server.mcpserver.MCPServer, the documented successor to fastmcp.FastMCP) and fastmcp-slim (latest, 3.4.5) still declares mcp<2.0, so the two cannot coexist in one lock. Adopting MCPServer resolves the conflict and removes ~24 transitive packages from the lock (keyring, secretstorage, jeepney, jaraco-*, openapi-pydantic, websockets, watchfiles, email-validator, ...). Mechanical surface (7 tool_registry_*.py files, mcp_progress.py, mcp_prompts.py, tool_error_handler.py, handlers/_tool_meta.py): FastMCP -> MCPServer in type annotations and imports; Context/ToolError imports moved to mcp.server.mcpserver / mcp.server.mcpserver.exceptions. Two architectural pieces mcp 2.0.0 has no drop-in equivalent for, each resolved by direct empirical verification against the installed package (not assumed from type signatures): 1. tool_profile_middleware.py — FastMCP's 4-hook Middleware (on_list_tools/on_call_tool/on_list_prompts/on_get_prompt) becomes ONE mcp.server.context.ServerMiddleware.__call__(ctx, call_next), dispatching on ctx.method. Rejecting a tools/call by raising before call_next (the naive port) loses the classified message — it skips MCPServer._handle_call_tool's own isError=True conversion and surfaces as a bare "MCPError: Internal server error". Fixed by constructing and returning a CallToolResult(is_error=True, ...) directly instead — the graceful, model-visible shape the original design intended (tool_error_handler.py's whole idiom). prompts/get has no in-band error shape, so that path still raises, but as mcp.shared.exceptions.MCPError specifically (the one class the dispatcher's error mapper recognizes and preserves the message for). Registered via MCPServer(middleware=[...]) at construction — no post-construction add_middleware() exists anymore. 2. stdio_transport.py (295 lines, the FastMCP-race workaround) — DELETED, not ported. Reproduced the exact scenario from its own removed regression test (deterministic anyio.Event synchronization, no sleeps) directly against bare mcp==2.0.0 in an isolated venv: the rewritten dispatcher (mcp.shared.jsonrpc_dispatcher .JSONRPCDispatcher.run) explicitly wraps the write-stream close OUTSIDE the task-group join, so a request still in flight at EOF always gets an explicit answer now -- the original silent-drop defect is fixed upstream. What is NOT reproduced: in-flight work is cancelled on EOF (not drained to completion), so the answer is a graceful CONNECTION_CLOSED error, not the handler's real result -- a narrower but still-correct guarantee (no silent drop, ever) this session initially over-claimed as full parity before checking the actual response payload, not just its presence. Replaced with test_stdio_late_response.py, a positive regression pin for the verified (not assumed) contract. __main__.py's main() is now anyio.run(mcp.run_stdio_async) -- the SDK also owns lifespan entry internally now, and there is no more banner/PyPI-update-check ceremony to preserve (mcp 2.0.0 does neither). Two further defects found only by full empirical round-trips, not by reading signatures: - mcp 2.0.0's MCPServer.tool() has no output_schema parameter at all -- structured output is derived exclusively from the wrapped function's return TYPE ANNOTATION. Every tool_registry_*.py inner function returned bare `-> dict`, which mcp 2.0.0 does not structure (no Tool.output_schema, no structuredContent) -- a universal regression across all 43 tools, not just the 9 with a hand-authored outputSchema. Fixed at the root: `-> dict` -> `-> dict[str, Any]` (mechanical, 43 occurrences) restores auto-derived structuredContent; a new apply_output_schemas() (handlers/_tool_meta.py) then overrides the auto-derived generic schema with each handler's hand-authored outputSchema by assigning tool.output_schema directly on the persistent internal Tool object (a cached_property, overridable via normal instance-__dict__ precedence) -- verified this persists across every subsequent tools/list call, unlike mutating the per-call wire-level mcp.types.Tool the old apply_param_docs() read from (also fixed to read the same persistent internal registry). - mcp 2.0.0's func_metadata no longer parses Google-style docstring Args: sections for prompt-argument descriptions (verified: no such logic anywhere in mcp.server.mcpserver.utilities.func_metadata). mcp_prompts.py's three prompt functions now declare descriptions via Annotated[str, Field(description=...)] instead. Test suite: 7046 of 7046 non-PG-gated tests pass (verified in an isolated venv with the full stack including flashrank installed); 264 skip (PostgreSQL-gated, expected without a live PG). mcp.Client's in-process transport wraps server errors in ExceptionGroup (anyio task-group teardown) where fastmcp.Client raised directly -- test assertions updated to unwrap; tests_py/test_mcp_prompts.py's helper needs ExceptionGroup/BaseExceptionGroup, 3.11+ builtins, so exceptiongroup>=1.2.0 (already a transitive anyio dependency) is now declared directly in the dev extras rather than relied on by luck. uv.lock + requirements/*.txt regenerated via `uv lock` + scripts/generate_pip_constraints.py. .craftsmanship-baseline.json surgically pruned (3 entries) for the deleted stdio_transport.py test files only -- not regenerated wholesale, to avoid grandfathering unrelated pre-existing debt the full-tree --write-baseline scan would otherwise have swept in from files this change never touches. Builds on investigation from an abandoned 2026-08-01 session (commits ba0821b8/86158b0d on the local feat/mcp-2.0 branch, never merged) that correctly identified both hard problems but did not verify its own tool_profile_middleware.py port against a real mcp.Client round-trip (it raises MCPError for tools/call too, which IS recognized and DOES preserve the message -- but changes tools/call rejections from a graceful isError=True result to a protocol-level error, a real, unverified behavior change) and did not reach stdio_transport.py at all. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(mcp2): keep the craftsmanship gate and lockfile in sync with the migration Two follow-ups the CI run on PR #331 caught immediately, both fixed at the source rather than baselined/skipped: - tests_py/infrastructure/test_stdio_late_response.py's test method exceeded the 40-line/method cap after the first extraction pass (the extracted helper itself was still over). Split further: a _RaceFixtures dataclass + _build_race_fixtures() groups the six-value setup into one call, leaving _drive_late_request_scenario() and the test method both under the cap. - pyproject.toml gained exceptiongroup>=1.2.0 in a later edit than the `uv lock` run in the prior commit — CI's `uv lock --check` correctly caught the resulting drift. Re-locked (uv.lock unchanged in content, since exceptiongroup was already pinned transitively at the same version — only the marker condition and provenance changed) and regenerated the 5 requirements/*.txt files whose extras include the dev group. Also adds .craftsmanship.conf (same fix as PR #332/#416, not yet on this branch since it was cut before those merged): the local zetetic-marketplace pre-commit hook has no auto-generated-file detection and flags requirements/*.txt against the generic §4.1 500-line cap. Scoped skip for requirements/, matching the documented auto-generated exception. Distinct from this repo's own CI gate (scripts/check_craftsmanship.py), unaffected by this file. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(mcp2): update the remaining hand-maintained fastmcp references Real bugs surfaced by CI running against the mcp 2.0.0 migration, not speculative cleanup: - scripts/launcher_pins.py: BASE_PACKAGES still pinned fastmcp==3.4.5 -- the plugin-bootstrap package list has no resolver available to catch drift itself, which is exactly why tests_py/scripts/test_launcher_pins_match_lock.py exists (compares this list against requirements/setup.txt on every PR) and is what caught this: `_BASE_PACKAGES disagrees with setup.txt`, failing every Test (Python 3.1x) leg on PR #331. Fixed to mcp==2.0.0. - scripts/setup.py: install_deps()'s hand-written package list had the same fastmcp>=2.0.0 entry, unguarded by a test (no equivalent to the launcher_pins check exists for this file). Fixed to mcp>=2.0.0 -- otherwise a fresh `setup.sh` run would install a package this repo no longer imports. - scripts/verify_mcp_hosts.py: refactored main() (Fowler 2018 Ch. 6, Extract Function) into _build_parser/_resolved_command/_case_command/ _run_one_case/_run_all_cases while touching this file for the PYTHONPATH fix -- the previous single function was already at the file's craftsmanship baseline (76 lines, nesting depth 5, both over CLAUDE.md's 40-line/3-level caps) and this PR's own edit was the trigger to fix it rather than add to it further. Both baseline entries pruned since neither violation reproduces anymore. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(mcp2): shrink verify_mcp_hosts.py functions back under the size caps The prior commit's refactor and PYTHONPATH-fix comment pushed two functions over CLAUDE.md's 40-line/method cap again (caught by CI's Craftsmanship Gate on push, not locally -- the pre-commit hook and the CI gate agree, this was a same-session miss, not a policy gap): - _environment(): the PYTHONPATH rationale moved from a 17-line inline comment to the module docstring's new "Environment isolation" section, leaving a two-line pointer at the call site. - _build_parser(): split into _add_selection_arguments (which host identities/profiles a run exercises) and _add_runtime_arguments (how each case is driven) -- the same split the module's own two concerns already implied. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(mcp2): drain before signalling shutdown in the stdio host harness PR #331's red CI was not a Cortex regression and not a race the mcp 2.0.0 SDK gets wrong: it was our harness asking for a guarantee the MCP protocol never grants. Model. Order the events of one batch: arrive(r) -> accept(r) -> begin(r) -> produce(r) -> enqueue(r) -> emit(r), against EOF -> readclose -> cancel -> join -> wclose. Serial reads over rendezvous streams force accept(r) -> EOF -> cancel for every request in the batch, and enqueue(r) -> emit(r) holds because stdout_writer lives outside the dispatcher's task group. Nothing orders enqueue(r) before cancel. The guarantee that is therefore nowhere established -- and that the harness assumed -- is the ANSWER OBLIGATION FOR AN ACCEPTED REQUEST: for every r the dispatcher takes off the read stream, exactly one frame carrying r's id reaches the wire. Mechanism, read from the pinned wheel (sha256 1cb4c75d...49d6, the hash uv.lock pins), not from its docs: JSONRPCDispatcher._handle_request sets answer_write_started on the line BEFORE awaiting the response write, and the shutdown arm declines to send CONNECTION_CLOSED whenever that flag is set ("prefer possibly-zero answers over possibly-two"). A write cancelled at MemoryObjectSendStream.send's entry checkpoint provably never delivered, yet counts as possibly sent -- so the request settles with no frame at all. Instrumented trace: begin(5) write_result-enter(5) send-cancelled-at-entry-checkpoint(5,CancelledError), then silence. This corrects the prior hypothesis (a handler task cancelled before its first scheduling turn); the handler ran to completion. Verdict. The SDK promises nothing here, and MCP 2025-06-18 §Lifecycle > Shutdown > stdio makes closing stdin the shutdown signal with no drain phase defined, so an accepted request is owed nothing once EOF lands. The defect is in the client: subprocess.run(input=...) signals shutdown before reading a single response. Reproduced against a BARE mcp 2.0.0 server with zero Cortex code -- ids 4 and 5 of a six-frame batch got no frame, 5/5 runs; the same batch drained first, 5/5 runs, loses nothing. Change. scripts/mcp_host_client.py owns the exchange and keeps stdin open until every expected id has arrived, closing it only then; synchronisation is by event (a response line, or stdout EOF), never by elapsed time -- the caller's --timeout survives only as a watchdog that kills a wedged child and never decides a verdict. stderr goes to a file, not an undrained pipe. verify_mcp_hosts.py drops to 276 lines, so its baselined file-size entry is pruned. mcp_server/__main__.py's main() comment claimed mcp 2.0.0 had the drain invariant built in; it does not, and the comment now says why the workaround is still not restored (a drain in our transport would let a wedged handler hold shutdown hostage, and real hosts never need it). Tests. test_stdio_eof_drain.py forces both orderings deterministically over one in-memory pair -- park the response write, then EOF: no frame; drain, then EOF: every real result. test_mcp_host_client.py pins that stdin is provably still open at each response read. test_stdio_late_response.py's docstring generalised one green interleaving into "no silent drop, ever"; that inference is retracted, with the scope it actually covers spelled out. Co-Authored-By: Claude <noreply@anthropic.com> * fix(mcp2): follow the harness split through its callers, and type the gate Two CI failures on the previous commit, both real: - tests_py/scripts/test_verify_mcp_hosts.py still imported `_environment` and `_responses` from scripts/verify_mcp_hosts.py, which no longer owns them. Retargeted at scripts/mcp_host_client.py; `_responses(stdout: str)` became `absorb(line, responses)` because the exchange reads one line at a time -- it must decide the batch is answered before it may close stdin, so it cannot wait for the whole stream. Added the case that change introduces: a blank line (the trailing newline whole-stream `splitlines()` never yielded) is not a malformed frame. - The sibling import is now `scripts.mcp_host_client` under one canonical name, with the repo root put on sys.path when this module runs as a script. A bare `import mcp_host_client` would give the executed script and an importing test two distinct module objects -- and two distinct `ContractError` classes, so `pytest.raises` would miss the real one. That dual-identity trap is already documented in tests_py/scripts/_craftsmanship_support.py for its own siblings. Also fixed, pre-existing on this branch and blocking the Type Check gate: mcp_server/tool_profile_middleware.py read `params["name"]` as `Any | None` and handed it to `allows()`/`is_available()`, both typed `str`. `_requested_name` now collapses a missing or non-string name to `""` -- which no profile lists, so both gates refuse it exactly as they already refused an unknown name. Behaviour is unchanged on every input; only the type is now honest. Co-Authored-By: Claude <noreply@anthropic.com> * test(mcp2): pin the drain rule's degenerate cases The exchange's termination argument has to hold at the corners, not only on the happy batch: a server that answers nothing (EOF before any frame) must report nothing and close, never block; a frame arriving after the last awaited id must still be parsed and contract-checked rather than discarded by the loop's exit; and ids are awaited as a SET, since mcp 2.0.0 runs handlers concurrently and does not answer in request order. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: cdeust <cdeust@icloud.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Review finding on PR #332: the prior comment called sympy 1.14.0's `mpmath<1.4` bound precautionary, on the strength of one working import+evalf call. The sympy maintainer's own issue tracker (sympy/sympy#29231) says otherwise: sympy 1.14.0 has a real, active dependency on a deprecated mpmath API (`mpf_log`), and an mpmath 1.4.0 ALPHA once broke `import sympy` outright before that got fixed. A sample of one code path working is not proof of general compatibility across sympy's much larger surface -- routing around a maintainer's bound requires knowing what it protects, not just testing that it doesn't (yet) bite the one call site checked. The practical decision is unchanged: this repo never imports sympy or mpmath directly (both arrive transitively through torch), so the deprecated-API surface sympy still touches is never exercised here, and the override remains safe to take. But it needed a ceiling: `override-dependencies = ["mpmath>=1.4.1"]` had no upper bound, so a routine `uv lock --upgrade` (not `--upgrade-package mpmath`) could pull a version sympy's own maintainer has already flagged as unsupported -- they state the next sympy release (1.15) will cap at `mpmath<1.5` specifically because of the alpha-0 breakage. Matched that ceiling: `mpmath>=1.4.1,<1.5`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
56bae9e to
c85fd5f
Compare
… overrides sympy 1.14.0 (latest) declares `mpmath<1.4,>=1.1.0` — a precautionary upstream bound, not a real incompatibility: mpmath 1.4.1 imports and evaluates correctly under sympy 1.14.0 (verified in an isolated venv, `sympy.sqrt(8).evalf()` -> 2.82842712474619). Added `[tool.uv] override-dependencies` in pyproject.toml so uv's resolver reaches the newer release instead of staying frozen behind it. That alone did not turn CI green. uv's override only affects uv's own resolution; the exported `requirements/*.txt` files carry no way to represent it, so `pip install --require-hashes -r <file>` re-derives dependency satisfaction from each package's own metadata and rejects mpmath 1.4.1 against sympy's declared `mpmath<1.4` bound — reproduced locally: the same file installs cleanly with `--no-deps` added, since these hash-pinned exports are already uv's complete, resolved closure and pip has no re-resolution left to do. Added `--no-deps` to every `pip install --require-hashes -r requirements/*.txt` call site (CI workflows, the shared test-suite composite action, all three Dockerfiles, and the ClusterFuzzLite build script) — the same pairing the local editable install already used, and for the same reason. uv.lock and requirements/*.txt regenerated via `uv lock --upgrade-package mpmath` + `scripts/generate_pip_constraints.py`; diff is mpmath-only. Verified: repo's craftsmanship gate, ruff check/format, constraint-generator `--check`, and the constraint/parity/typecheck-env test suites all pass locally. Also adds .craftsmanship.conf: the local zetetic-marketplace pre-commit hook (craftsmanship-checker.sh, distinct from this repo's own CI gate) has no auto-generated-file detection, so it flagged requirements/*.txt against the generic §4.1 500-line cap. Scoped skip for requirements/, matching the documented auto-generated exception. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Review finding on PR #332: the prior comment called sympy 1.14.0's `mpmath<1.4` bound precautionary, on the strength of one working import+evalf call. The sympy maintainer's own issue tracker (sympy/sympy#29231) says otherwise: sympy 1.14.0 has a real, active dependency on a deprecated mpmath API (`mpf_log`), and an mpmath 1.4.0 ALPHA once broke `import sympy` outright before that got fixed. A sample of one code path working is not proof of general compatibility across sympy's much larger surface -- routing around a maintainer's bound requires knowing what it protects, not just testing that it doesn't (yet) bite the one call site checked. The practical decision is unchanged: this repo never imports sympy or mpmath directly (both arrive transitively through torch), so the deprecated-API surface sympy still touches is never exercised here, and the override remains safe to take. But it needed a ceiling: `override-dependencies = ["mpmath>=1.4.1"]` had no upper bound, so a routine `uv lock --upgrade` (not `--upgrade-package mpmath`) could pull a version sympy's own maintainer has already flagged as unsupported -- they state the next sympy release (1.15) will cap at `mpmath<1.5` specifically because of the alpha-0 breakage. Matched that ceiling: `mpmath>=1.4.1,<1.5`. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The previous push shipped placeholder (--ours) conflict resolutions for the 9 requirements/*.txt files from an earlier rebase, never replaced by the actual regeneration against the merged uv.lock before commit — so mpmath silently reverted to 1.3.0 in the exports while uv.lock correctly carried 1.4.1. python scripts/generate_pip_constraints.py --check now passes; mpmath 1.4.1's two hashes re-verified against PyPI. Co-Authored-By: Claude <noreply@anthropic.com>
c85fd5f to
0e1dbe1
Compare
|
ZETETIC-REVIEW: APPROVE Fresh verdict on head
The recurring Lint failure was not a formatting problem. The first diagnosis — A second trap was caught on the way: a local run went green against a stale Green: 23 pass, 0 fail, 2 skipping — including the Lint job that failed on the three previous heads, which is what makes this a discriminating signal rather than a quiet one. Scope check: a dependency bump carries a dependency bump. The Docker Smoke stdin-close race found while triaging this batch was deliberately kept out and is being handled on its own contract. |
1 participant
Bumps mpmath from 1.3.0 to 1.4.1.
Release notes
Sourced from mpmath's releases.
... (truncated)
Changelog
Sourced from mpmath's changelog.
... (truncated)
Commits
c1131e2Merge pull request #1053 from skirpichev/release-1.4.1d3d3eb9Update CHANGES629daffAdd a workaround for test on s390x96272f3Revert "Add backport action"e129480Test frozen package version (#1055)1ef88b4Amend docstring for round_digits()650520bUse version_file option of setuptools-scm to keep version info501af4aKeep forever deprecated aliases for mpc/mpf_log()6887127Set argtypes for sprintf from ctypesf3e9cf0Update CHANGES (free-threading support)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)