modelcontextprotocol / modelcontextprotocol/python-sdk
pyjwt[crypto] as an unconditional dependency blocks installation on platforms without a cryptography wheel (e.g. Windows on ARM)
還沒有人認領這個 Issue。
- 主要語言
- Python
- 星號
- 24.3k
- 分支
- 4k
- 平均合併
- 1 天 1 小時
- 30 天內合併 PR
- 31
描述
Summary
pyjwt[crypto] is declared as an unconditional Requires-Dist in mcp's package metadata, even though the crypto extra (and the jwt import it enables) is only used by one file: mcp/client/auth/extensions/client_credentials.py, an OAuth client-credentials flow. Every consumer of this package — including a pure MCP server implementation that never acts as an OAuth client — is forced to install pyjwt[crypto], which pulls in cryptography as a hard dependency.
Why this matters
cryptography ships prebuilt wheels for most platforms, but not all — e.g. there is currently no PyPI wheel for win_arm64 (Windows on ARM). On a platform without a prebuilt wheel, pip/uv fall back to building cryptography from source via maturin/cargo/rustc, which additionally requires a working Rust toolchain and the MSVC linker (link.exe, part of Visual Studio Build Tools) to be present. A user with a plain Python install (no Visual Studio, no Rust) hits a hard installation failure:
error: linker `link.exe` not found
note: the msvc targets depend on the msvc linker but `link.exe` was not found
note: please ensure that Visual Studio 2017 or later, or Build Tools for
Visual Studio were installed with the Visual C++ option
This blocks installing mcp (and anything depending on it) entirely on that platform, for a feature (OAuth client-credentials auth) the user may never use — in our case, a Community-Edition-facing MCP server package that has no OAuth-client code path at all.
Suggested fix
mcp already uses the extras pattern for other optional functionality (cli, rich in the current metadata). Moving the OAuth client-credentials code's pyjwt[crypto] requirement behind its own extra (e.g. oauth or similar) would let server-only/non-OAuth-client consumers install mcp without pulling in cryptography at all, while OAuth-client users opt in explicitly with mcp[oauth].
Environment where this was found
- Windows on ARM64 (win_arm64), Python 3.14 (win_arm64 build)
- Both
pip(venv fallback) anduv synchit the identical build failure - Confirmed
cryptographyhas nowin_arm64wheel on PyPI as of writing; onlywin_amd64prebuilt wheels exist for this release - No Visual Studio / Build Tools installed (a normal state for an end user who is not a C/C++ developer)
Happy to provide the full build log if useful.
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
檢查套件中繼資料宣告和 mcp/client/auth/extensions/client_credentials.py,然後在受影響的平台上使用 pip 或 uv 重現安裝流程。完成標準是:僅安裝伺服器時不再需要 cryptography,而 OAuth 用戶端使用者可以透過專用 extra 選擇啟用它;驗證最終的封裝與安裝行為。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- python
- 領域
- authentication, build-system
- Issue 類型
- 缺陷
- 難度
- 2/5
- 預估耗時
- 1-3 小時
- 活躍度
- 活躍
- 描述清晰度
- 基本清楚
- 新手友好度
- 75/100