[vvillait88]

Summary

Maintenance sweep, lock-only (no pyproject or source change). Requested by Varun as part of the weekly sweep. Notable moves:

• pytempo 0.6.2 to 0.7.0, under pympp's tempo extra. Read from the wheel diff: additive for every symbol pympp 0.11 imports (Call, TempoTransaction, sign_tx_access_key, Signature, as_address). It adds P256/WebAuthn signatures and transaction decoding, and now rejects valid_after >= valid_before when both are set, matching the Tempo node's own rule.
• python-dateutil 3.0.0 to 4.0.0, under cdp-sdk (coinbase extra), inside cdp-sdk's declared range; six drops out with it.
• OpenTelemetry 1.45.2 / 0.66b2, pydantic 2.14.2, stripe 16.1.0, anyio, trio, ty and others.

Holds unchanged: pympp stays at 0.11 and web3 below 8 (dependency holds registry).

No release: the change is uv.lock only, so the wheel and the installed package cannot change.

Type of change

• Bug fix (no breaking change)
• New feature (no breaking change)
• Breaking change (existing callers must update)
• Docs, tests, or internal maintenance only

Public API

none

Test plan

Ran locally after uv sync --all-extras --all-groups: ruff check, ruff format --check, ty (package and examples), vulture and pytest (1674 passed, coverage 97.44%) all exit 0. osv-scanner with the repo config: no issues across 162 packages.

Checklist

• Tests cover the new behavior, and the suite passes locally
• Lint, format, and type checks pass
• Docs and README examples updated if the public surface changed (nothing public changed)
• No secrets, credentials, or personal data in the diff or the tests

🤖 Generated with Claude Code

[vvillait88]

Review: lock-only sweep refresh

Verdict: safe to merge, and no release is needed. I found no defects. All checks below ran on a worktree of 744a314, branched from current main 131ba32.

Diff

Only uv.lock changes. The full set of moves, extracted from the diff:

• anyio 4.16.0, dnspython 2.9.1, google-api-core 2.43.2
• the OpenTelemetry family at 1.45.2 and 0.66b2
• pydantic 2.14.2 with pydantic-core 2.50.2
• pytempo 0.6.2 to 0.7.0
• pytest-asyncio 1.4.1.post1
• python-dateutil 3.0.0 to 4.0.0
• python-multipart 0.0.33, sqlparse 0.6.1
• stripe 16.1.0
• trio 0.35.0, ty 0.0.95, types-requests 2.33.0.20261030, wrapt 2.5.2
• six removed

Gates

All run as ci.yml invokes them, with each exit code read separately:

• uv sync --frozen --all-extras --all-groups: 0
• ruff check .: 0
• ruff format --check .: 0 (202 files)
• ty check agentscore_commerce/: 0
• ty check on examples: 0
• vulture . --min-confidence 80 --exclude .venv: 0
• pytest tests/: 0, with 1674 passed, 4 skipped and 97.44% coverage

pytempo 0.7.0: the change cannot reach a path python-commerce runs

I diffed the two wheels from PyPI. Only __init__.py, keychain.py and models.py changed, and signatures.py is new.

• Additive for pympp. The pytempo imports in pympp 0.11 are Call, TempoTransaction, sign_tx_access_key, Signature and as_address.
  • All five still exist. The signature of sign_tx_access_key is byte-identical.
  • The method diff of models.py and keychain.py only adds methods: decode, recover_*, sign_with, and the P256 and WebAuthn types.
  • __all__ only grows.
  • Importing every pympp tempo module against 0.7.0 succeeds.
• What the stricter rule changes. In 0.6.2, validate() raised only when valid_after > valid_before. In 0.7.0 it raises when valid_after >= valid_before, and only when both are non-zero. A 0 now counts as absent, which loosens the old is not None test in the other direction. The new rule matches the node's own strict rule, so the only transaction it newly refuses is one the chain would refuse anyway.
• Where pympp's server side reaches validate(). On the server side, pympp 0.11 builds a TempoTransaction only in _cosign_as_fee_payer, and it calls get_signing_hash there, which runs validate().
  • That function runs only when request.methodDetails.feePayer is set AND a fee_payer account is configured on the method.
  • _validate_transaction_payload decodes with raw rlp, not with pytempo.
• python-commerce never configures a fee payer. _tempo_method in agentscore_commerce/payment/mppx_server.py calls tempo(intents=..., currency=..., recipient=..., chain_id=...) and never passes fee_payer, whose default is None according to inspect.signature.
  • Nothing in agentscore_commerce/ or examples/ touches mpp.client, TempoAccount or the cosign path.
  • tests/ does not reference pytempo directly.
  • The only route to the new check is a merchant who hand-builds a TempoMethod with fee_payer= and passes it as method=. There, the check rejects only a window the node already rejects.
• Merchants get 0.7.0 regardless of this lock. pympp requires pytempo>=0.2.1 with no upper bound, so a fresh agentscore-commerce[mppx] install already resolves it. The green suite on 0.7.0 is the useful evidence here.

python-dateutil 4 and six

• cdp-sdk 1.51.0 requires python-dateutil>=2.9.0, so 4.0.0 is within its range.
• python-commerce itself never imports dateutil.
• The one package that still mentions six, json-rpc (under a2a-sdk, dev group), imports its own vendored copy (from . import six). No module in the venv imports a top-level six, and import jsonrpc.jsonrpc2, jsonrpc.utils succeeds.

Holds and uv prerelease rules

• pympp: it stays at 0.11.0. PyPI's latest, 0.18.0, still pins yarl==1.24.5 and propcache==0.5.2 in the tempo, stripe and mcp extras, so the lift condition in the aiohttp>=3.14.4 floor entry is not met.
• web3: it stays at 7.16.0 under constraint-dependencies = ["web3<8"]. pympp 0.18 still declares eth-abi<6,>=5.0, so that lift condition is not met either. solana 0.40.1 and eth-abi 5.2.0 are the expected consequences.
• requires-python: it is >=3.11, which respects the floor of 3.14 or lower.
• Prereleases: a scan of uv.lock finds exactly three: opentelemetry-semantic-conventions, -exporter-http-transport and -exporter-otlp-common at 0.66b2. All belong to the never-stable family that prerelease = "if-necessary" admits on purpose, and the lock holds no other a, b or rc version.
• Nothing else to take:
  • uv lock --upgrade --dry-run reports "No lockfile changes detected".
  • Against PyPI, every direct dependency, extra and dev dependency is at its latest except the four held above.
  • django carries two versions: 5.2.18 for python_full_version < '3.12', and 6.1.2 elsewhere, because 6.1.2 requires Python 3.12 or later. That fork is correct.

No release

uv build on main and on the head gives identical wheel shasums (85486a62...). In the sdist (236 files), diff -rq reports exactly one differing file, the bundled uv.lock.

CI

gh pr checks 171 exits 0, and all 12 rows pass: ci, test 3.11 through 3.15, Dependency Scan, Python Audit, CodeQL and Analyze.