[Feature]: relax the pyee upper-bound pin (currently <14) in pyproject.toml
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 2/5
- 預估耗時
- 1-3 小時
- 新手友好度
- 75/100
- Issue 類型
- 功能
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- python
- 領域
- build-system
研究方向
依賴項固定位於 pyproject.toml 和 meta.yaml 中。首先，在儲存庫根目錄中找到這些檔案。檢查 pyee 的目前版本約束。要測試變更，請將約束更新為 '>=13'（或謹慎起見，使用 '>=13,<15'）。執行專案的測試套件以確保與 pyee 14.0.0 的相容性。尋找任何驗證依賴項的 CI 設定或腳本。
由索引模型根據 Issue 內容生成。
描述
(Filing here rather than in microsoft/playwright — the pin lives in this repo's pyproject.toml/meta.yaml, and prior reports of the same class of issue, #2190 and #2666, were both handled directly in playwright-python rather than redirected. The "please file at microsoft/playwright" notice on this tracker appears to be specific to the playwright-mcp bug template, not Python packaging issues.)
🚀 Feature Request
playwright currently pins pyee<14,>=13 (unchanged across the 1.62.0 → 1.63.0 release). pyee 14.0.0 was released on 2026-08-12 — over a month ago — but installing playwright alongside pyee==14.0.0 (or any other package that requires it) fails with a dependency-resolution conflict:
ERROR: Cannot install -r requirements.txt (line N) and pyee==14.0.0 because these package versions have conflicting dependencies.
ERROR: ResolutionImpossible
Looking at pyee's 14.0.0 changelog, the changes are: switching the build tooling to uv, dropping Python 3.8–3.11 support, and a bugfix to remove_all_listeners (only removing listeners for the specified event). None of that looks like it should be a breaking change for the subset of pyee's EventEmitter API playwright uses — but I haven't run playwright's own test suite against it to confirm.
Example
pip install playwright pyee==14.0.0
should not raise ResolutionImpossible.
Motivation
We run playwright in CI alongside other dependencies that have already moved to pyee 14.x (via automated dependency updates), and the pin blocks that upgrade from landing.
A ceiling tied to "next major version" (<14, or even <15 after a one-time bump) isn't a durable fix here — pyee's own release history shows it doesn't reserve major version bumps for actual breaking changes: 9.0.0 → 14.0.0 in about 4 years, several majors released within days of the prior one, and 14.0.0 itself is a Python-support drop plus a bugfix, not an API break. A hard major-version ceiling on a dependency with that release pattern will go stale almost every time pyee publishes anything, recreating this exact issue repeatedly. We'd suggest dropping the upper bound entirely (pyee>=13) rather than replacing one ceiling with another — closer to what #2698 did for greenlet, whose bound was widened rather than left to go stale again.
Claude on behalf of e2jk
- 主要語言
- Python
- 星號
- 15k
- 分支
- 1.2k
- 平均合併
- 3 天 2 小時
- 30 天內合併 PR
- 9
環境準備
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
microsoft/playwright-python 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 68/100
microsoft/playwright-python#3186 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 45/100
microsoft/playwright-python#3216 ·
維護者通常 1 天內回覆
-
[Feature]: Official APIs to resolve/map ephemeral aria-refs to stable locators for LLM automation未關閉
難度 4/5 3-5 天 新手友好度 35/100
microsoft/playwright-python#3207 ·
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 1/100
microsoft/playwright-python#3195 ·
維護者通常 1 天內回覆
-
難度 3/5 1-2 天 新手友好度 72/100
microsoft/playwright-python#3188 ·
維護者通常 1 天內回覆
查看 microsoft/playwright-python 的全部 Issue
相似的 Issue
-
難度 1/5 1 小時以內 新手友好度 72/100
letsencrypt/cp-cps#353 ·
-
難度 2/5 1-3 小時 新手友好度 68/100
-
難度 2/5 1-3 小時 新手友好度 84/100
PedestrianDynamics/pyFDS-Evac#394 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
DOI-USGS/pywatershed#421 ·
-
難度 2/5 1-3 小時 新手友好度 78/100
python-pillow/Pillow#10087 · 1 則留言 ·
維護者通常 1 天內回覆