Escaping Python Dependency Hell: A Hybrid Replay-and-Repair Pipeline for Python Dependency Resolution

逃离 Python 依赖地狱：一种用于 Python 依赖解析的混合重放与修复流水线

Abstract: Dependency conflicts in Python ecosystems arise from incompatible version constraints, missing packages, and undocumented compatibility relationships, causing many real-world code snippets to fail at execution. This paper presents PLLM+, a hybrid dependency-repair pipeline evaluated on the HG2.9K benchmark of 2,891 dependency-failing snippets.

摘要： Python 生态系统中的依赖冲突通常源于不兼容的版本约束、缺失的包以及未记录的兼容性关系，导致许多现实世界的代码片段在执行时失败。本文提出了 PLLM+，这是一种混合依赖修复流水线，并在包含 2,891 个依赖失败代码片段的 HG2.9K 基准测试集上进行了评估。

PLLM+ prioritizes inexpensive deterministic steps before invoking LLM-based repair: static AST-based interpreter inference, replay of historically successful dependency configurations from the competition-provided solutions database, and live PyPI validation of candidate package versions. When these steps do not resolve a case, the system falls back to a structured LLM-based repair loop with typed error classification and Proposer/Critic agents.

PLLM+ 在调用基于大语言模型（LLM）的修复之前，优先执行低成本的确定性步骤：包括基于静态 AST 的解释器推断、重放来自竞赛提供的解决方案数据库中历史成功的依赖配置，以及对候选包版本进行实时的 PyPI 验证。当这些步骤无法解决问题时，系统会回退到结构化的 LLM 修复循环，该循环结合了类型化错误分类以及“提议者/评论者”（Proposer/Critic）智能体机制。

On HG2.9K, PLLM+ solves 1,500 out of 2,891 snippets, compared with 1,169 solved by the PLLM baseline. It also reduces average runtime from 368.7 to 71.8 seconds per snippet. Most successful fixes come from replaying known configurations: 1,495 of the 1,500 successful fixes are produced by the solutions database, while the LLM fallback accounts for 5 additional fixes.

在 HG2.9K 基准测试中，PLLM+ 成功解决了 2,891 个代码片段中的 1,500 个，而 PLLM 基准模型仅解决了 1,169 个。此外，它将每个代码片段的平均运行时间从 368.7 秒缩短至 71.8 秒。大多数成功的修复来自于重放已知的配置：在 1,500 个成功修复中，有 1,495 个是由解决方案数据库生成的，而 LLM 回退机制仅贡献了额外的 5 个修复。

These results suggest that, in this benchmark setting, deterministic reuse of previously validated dependency configurations is a simple and effective strategy, with LLM-based repair serving as a secondary fallback for cases not covered by prior solutions.

这些结果表明，在此基准测试环境下，确定性地重用先前验证过的依赖配置是一种简单且有效的策略，而基于 LLM 的修复则作为无法被先前解决方案覆盖的情况下的次要回退手段。