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

arXiv: https://arxiv.org/abs/2609.26952 · HTML: https://mlsanity.com/paper/2609.26952/

## Key facts

- No citing papers in the map yet (data through 14 Oct 2026).
- Builds on 11 of its 19 references that are in the map.
- First posted on arXiv 22 Sep 2026.

## Builds on (most cited first, 11 of 11)

- [Improving Factuality and Reasoning in Language Models through Multiagent Debate](https://mlsanity.com/paper/2305.14325/) (2023)
- [RepairAgent: An Autonomous, LLM-Based Agent for Program Repair](https://mlsanity.com/paper/2403.17134/) (2024)
- [A Survey of LLM-based Automated Program Repair: Taxonomies, Design Paradigms, and Applications](https://mlsanity.com/paper/2506.23749/) (2025)
- [Do Developers Update Their Library Dependencies? An Empirical Study on the Impact of Security Advisories on Library Migration](https://mlsanity.com/paper/1709.04621/) (2017)
- [DockerizeMe: Automatic Inference of Environment Dependencies for Python Code Snippets](https://mlsanity.com/paper/1905.11127/) (2019)
- [When Judgment Becomes Noise: How Design Failures in LLM Judge Benchmarks Silently Undermine Validity](https://mlsanity.com/paper/2509.20293/) (2025)
- [AgentMesh: A Cooperative Multi-Agent Generative AI Framework for Software Development Automation](https://mlsanity.com/paper/2507.19902/) (2025)
- [Less is More? An Empirical Study on Configuration Issues in Python PyPI Ecosystem](https://mlsanity.com/paper/2310.12598/) (2023)
- [PyRadar: Towards Automatically Retrieving and Validating Source Code Repository Information for PyPI Packages](https://mlsanity.com/paper/2404.16565/) (2024)
- [The Last Dependency Crusade: Solving Python Dependency Conflicts with LLMs](https://mlsanity.com/paper/2501.16191/) (2025)
- [Gistable: Evaluating the Executability of Python Code Snippets on GitHub](https://mlsanity.com/paper/1808.04919/) (2018)

## Abstract (arXiv)

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. 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. 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. 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.