modelcontextprotocol / modelcontextprotocol/python-sdk

pyjwt[crypto] as an unconditional dependency blocks installation on platforms without a cryptography wheel (e.g. Windows on ARM)

未关闭 适合新手
#3,373 6 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

v1 v2
主要语言
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) and uv sync hit the identical build failure
  • Confirmed cryptography has no win_arm64 wheel on PyPI as of writing; only win_amd64 prebuilt 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.

贡献指南

打开贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 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

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。