Specify working pydantic version

[komod0]

User description

Pip and other package manager started resolving the pydantic dependency(used by FastMCP i believe) to versions >= 2.12.0 which seems to break with the error:
TypeError: cannot specify both default and default_factory
as described in #271

Fixes #271

---

PR Type

Bug fix

---

Description

• Restrict pydantic version to <2.12.0 to avoid compatibility issues

• Resolves TypeError with default and default_factory conflict

• Pins working pydantic version range in dependencies

---

Diagram Walkthrough

flowchart LR
  A["pydantic>=2.5.1"] -- "constrain upper bound" --> B["pydantic>=2.5.1,<2.12.0"]
  B -- "prevents TypeError" --> C["Resolves issue #271"]

Loading

File Walkthrough

	Relevant files
Dependencies	pyproject.toml Constrain pydantic version upper bound                                      pyproject.toml Updated pydantic dependency constraint from >=2.5.1 to >=2.5.1,<2.12.0 Prevents package managers from resolving to incompatible versions >= 2.12.0 Fixes TypeError related to conflicting default and default_factory parameters +1/-1

---

Summary by CodeRabbit

• Chores
  • Updated pydantic dependency with an upper version bound to restrict supported versions.

[Copilot]

Pull Request Overview

This PR fixes a compatibility issue with pydantic by restricting its version range to exclude versions >= 2.12.0, which cause a TypeError: cannot specify both default and default_factory error.

• Updated pydantic dependency constraint to cap the maximum version at 2.12.0

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[coderabbitai]

Walkthrough

Updated the pydantic dependency version constraint in pyproject.toml from pydantic>=2.5.1 to pydantic>=2.5.1,<2.12.0, adding an upper bound to exclude pydantic versions 2.12.0 and above.

Changes

Cohort / File(s)	Change Summary
Dependency constraint pyproject.toml	Pydantic version constraint updated to include upper bound; changed from pydantic>=2.5.1 to pydantic>=2.5.1,<2.12.0

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Poem

🐰 A version constraint, small but true,
Pydantic now bounded, old and new,
No more crashes when the fields collide,
With defaults and factories side by side! ✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues Check	⚠️ Warning	The PR implements one of the suggested solutions from issue #271 by pinning the pydantic dependency to exclude incompatible versions (>= 2.12.0). However, issue #271 explicitly requests that when dependency pinning is used as a fix, the PR should include tests or CI checks to prevent regressions across pydantic versions and update release notes/installation guidance if needed. The current PR changes only the dependency declaration without addressing these required complementary changes. Tests, CI checks, and documentation updates are coding-related requirements that are absent from this submission.	To meet the full requirements of issue #271, add tests or CI checks to verify the fix works across pydantic versions and Python 3.13 environments, and update release notes or installation documentation to communicate the pydantic version constraint to users. These additions are necessary complements to the dependency pinning strategy and were explicitly requested in the issue.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "Specify working pydantic version" directly and accurately describes the main change in the changeset. The raw summary confirms that the only modification is updating the pydantic dependency to add an upper bound (from "pydantic>=2.5.1" to "pydantic>=2.5.1,<2.12.0"), which is precisely what the title conveys. The title is concise, clear, and specific enough for a teammate scanning the history to understand the primary change without ambiguity.
Out of Scope Changes Check	✅ Passed	All changes in the PR are directly related to addressing the scope of issue #271. The only modification is updating the pydantic dependency to pin a compatible version, which is one of the explicitly mentioned solutions in the linked issue for fixing the startup crash. No unrelated files have been modified, and no extraneous changes have been introduced beyond what is necessary to implement the dependency pinning strategy.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5c21e5d and 4719e2a.

📒 Files selected for processing (1)

• pyproject.toml (1 hunks)

🔇 Additional comments (1)

pyproject.toml (1)

27-27: Based on my verification, I have sufficient evidence to generate the rewritten review comment. The original concerns are substantiated, and I have concrete data about fastmcp versions and pydantic compatibility.

---

Version pinning is a workaround; investigate root cause before merging.

The pydantic <2.12.0 upper bound addresses a real incompatibility in fastmcp (which mcpm pins at 2.10.2), but this is a band-aid that creates long-term maintenance burden. Per PR objectives, prioritized solutions are: (1) fix model/field definitions, (2) add compatibility handling, (3) version pin as last resort. Before merging, verify:

• Was the root cause investigated? (fastmcp uses both default and default_factory in pydantic Field definitions)
• Can fastmcp be upgraded? (2.12.5+ released Oct 17, but changelog shows no pydantic 2.12 fixes)
• Why wasn't code-level fixing or compatibility handling explored?

Version capping will block pydantic 2.12+ indefinitely unless fastmcp fixes its code or mcpm patches it locally. This is a decision that warrants documented investigation.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟡	🎫 #271 🟢 Adjust dependencies so package managers do not resolve to incompatible Pydantic versions that trigger the error. ⚪ Fix startup failure when running mcpm/mpc caused by Pydantic error "TypeError: cannot specify both default and default_factory". Provide a solution that works on Linux environments (e.g., Debian 13, Gentoo) and for MCPM version 2.9.0 users.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
⚪	No custom compliance provided Follow the guide to enable custom compliance check.

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

No code suggestions found for the PR.

[GabrielDrapor]

Thanks❤️

[mcpm-semantic-release]

🎉 This PR is included in version 2.10.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀