MPT-23808 Cap typer at 0.26 to keep mpt-tool co-installable with the SDK - #95
Merged
Conversation
… SDK Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
🔗 Linked repositories identifiedCodeRabbit considers these linked repositories for cross-repo context during reviews:
📜 Recent review details⏰ Context from checks skipped due to timeout. (1)
🧰 Additional context used📓 Path-based instructions (1)**/*⚙️ CodeRabbit configuration file
Files:
🔇 Additional comments (2)
📝 WalkthroughWalkthroughThe project now constrains ChangesTyper dependency constraint
Estimated code review effort: 1 (Trivial) | ~5 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
Comment |
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
robcsegal
approved these changes
Aug 4, 2026
d3rky
approved these changes
Aug 4, 2026
svazquezco
added a commit
to softwareone-platform/mpt-installation-extension
that referenced
this pull request
Aug 5, 2026
🤖 AI-generated PR — Please review carefully. ## What was done Bump `mpt-extension-sdk` from 6.5.2 to **6.6.2**. Since 6.6 falls outside the previous `==6.5.*` pin, this updates: - `backend/pyproject.toml`: pin `mpt-extension-sdk[azure-monitor]==6.5.*` → `==6.6.*`. - `.pre-commit-config.yaml`: matching pin in the mypy hook's `additional_dependencies`. - `backend/uv.lock`: SDK 6.6.2, plus `mpt-api-client` 6.3.1 → 6.4.0 and `mpt-tool` 6.0.1 → 6.0.4 (see below). - `backend/tests/conftest.py`: pass `auth` when building the agreement context. ### Why mpt-tool moves too SDK 6.6.2 requires `mpt-api-client==6.4.*`, which the published `mpt-tool` releases blocked until now: 6.0.2 pinned `mpt-api-client==6.3.*`, and 6.0.3 fixed that but shipped `typer==0.27.*`, which collides with the SDK's `typer==0.26.*` (capped by mrok, kept in lockstep per MPT-22658) — so resolution was unsatisfiable either way and the lock could only reach 6.6.1. mpt-tool 6.0.4 (softwareone-platform/mpt-tool#95) caps typer back at 0.26 while keeping `mpt-api-client==6.4.*`, which unblocks 6.6.2 here with no pin gymnastics or `override-dependencies` in this repo. ### Why the conftest change SDK 6.6 makes `auth` a required field on `BaseContext` (MPT-23514), so every `AgreementContext` construction must provide it. Only the test factory builds contexts directly — production code receives the context from the SDK — so the fixture now builds a real `AuthContext`, per the shared unit-testing standard's preference for real value objects over mocks. Its `extension_id` matches the `runtime_settings` stub so the context stays self-consistent; the token is a module constant to keep the literal out of the call (ruff `S106`), and the SDK's auth `Account` is aliased as `AuthAccount` to avoid colliding with the agreement `Account` model. `InstallationAgreementContext.from_context` copies init fields generically, so no adapter change was needed. The lenient status enums introduced in 6.6.2 (`AgreementStatus`, `LicenseeStatus`, …) needed no changes here — they accept the existing string values. ## Testing - Backend lint suite passes (ruff format/check, flake8, mypy, `uv lock --check`). - Backend tests pass (39 tests). - Rebased onto current `main` (a90851b) and revalidated. Jira: [MPT-23808](https://softwareone.atlassian.net/browse/MPT-23808) 🤖 Generated with [Claude Code](https://claude.com/claude-code) [MPT-23808]: https://softwareone.atlassian.net/browse/MPT-23808?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- This is an auto-generated comment: release notes by coderabbit.ai --> - Update `mpt-extension-sdk` from the `6.5` line to `6.6.*`. - Update dependency pins in `backend/pyproject.toml` and `.pre-commit-config.yaml`. - Resolve `mpt-extension-sdk` 6.6.1 and `mrok` 0.10.5 in `backend/uv.lock`. - Add the required `auth` field to the agreement context test fixture. - Keep SDK 6.6.2 excluded because it conflicts with `mpt-tool` 6.0. - Pass lint checks, lock verification, and 38 backend tests. <!-- end of auto-generated comment: release notes by coderabbit.ai -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
🤖 AI-generated PR — Please review carefully.
Problem
mpt-tool 6.0.3 cannot be installed alongside
mpt-extension-sdk6.6.x, so extension repos cannot pick up SDK 6.6.2. Resolution fails outright:The cap is not arbitrary:
mrok(latest 0.10.5, a dependency of the SDK) requirestyper<0.27.0,>=0.26.0, and the SDK keeps mrok/fastapi/typer pinned in lockstep for that reason (MPT-22658). The SDK cannot move to typer 0.27 until mrok lifts its cap — mpt-tool has no such constraint of its own, so it is the side that should hold.typer reached 0.27 here through an unreviewed Dependabot bump (commit
0e9b43e, 2026-07-27), which touched onlypyproject.tomlanduv.lock— nothing in mpt-tool actually needed 0.27.What was done
pyproject.toml:typer==0.27.*→==0.26.*, with a comment recording why the cap exists.mpt-api-client==6.4.*is left untouched.uv.lock: refreshed — typer 0.27.0 → 0.26.8. Nothing else moves..github/dependabot.yml: ignoretyper >=0.27so the next scheduled run cannot silently reintroduce the conflict. This mirrors the guard the SDK already carries for the same reason.Reverting typer is behaviourally safe: the only breaking change in 0.27.0 is metavar rendering in
--helpoutput (typer#1863) — types shown as<str>instead ofTEXT, choices as<a|b>instead of[a|b]— and 0.27.1 only adjusts epilog formatting. No API or argument-parsing changes. mpt-tool declares its metavars explicitly inmpt_tool/cli.py, which both versions honour.Testing
ruff format --check,ruff check,flake8,mypy,uv lock --checkall pass.mpt-extension-sdk[azure-monitor]==6.6.*andmpt-extension-contrib-custom-notifications[teams]==1.2.*resolves cleanly to SDK 6.6.2 with mpt-api-client 6.4.0 and typer 0.26.8, confirming no further hidden conflict.Follow-up
This needs a release (6.0.4) to reach PyPI before extensions can move to SDK 6.6.2; the currently published 6.0.3 stays unusable with 6.6.x. Once mrok lifts its
typer<0.27cap, the ignore rule here and in the SDK can both be dropped and the two can move up together.Jira: MPT-23808
🤖 Generated with Claude Code
mpt-toolto usetyper 0.26.*.uv.locktotyper 0.26.8.typerto version0.27or later.mpt-extension-sdk6.6.x.