PLLM+: A Hybrid Replay-and-Repair Pipeline for Solving Python Dependency Hell

Python Dependency Conflicts: An Old Problem, A New Solution

Anyone who has written Python has almost certainly hit the dependency hell wall. Incompatible version constraints, missing packages, undocumented compatibility relationships — these issues cause countless seemingly normal code snippets to crash at runtime. For researchers, educators, and engineers who need to reproduce historical code, the frustration of "can't get it running" is real and recurring.

A newly published arXiv paper (arXiv:2609.26952v1) introduces a hybrid dependency repair pipeline called PLLM+, which attempts to systematically address this persistent problem. Its core approach is worth noting: rather than immediately reaching for expensive large language models, it first applies cheap, deterministic methods to solve problems — keeping LLMs as a last resort.

PLLM+ paper source screenshot

PLLM+'s Layered Repair Strategy

Cheap First, Expensive Last

PLLM+'s most distinctive design philosophy is "prioritize low-cost deterministic steps." The entire pipeline is arranged from lowest to highest cost across several stages:

Static AST interpreter inference: Analyzes the abstract syntax tree to infer the interpreter environment required by the code;
Historical success configuration replay: Replays previously validated dependency configurations from a competition-provided solution database;
Real-time PyPI validation: Verifies candidate package versions online to confirm their actual availability.

Only when all of these deterministic steps fail to resolve a given case does the system fall back to the LLM-based structured repair loop.

An Abstract Syntax Tree (AST) is a tree-structured representation of source code, where each node corresponds to a syntactic construct (such as function calls, import statements, or variable assignments). Python's built-in ast module can parse source files without actually executing them, statically extracting dependency information from import and from...import statements. The advantage of this static analysis is zero runtime cost with no environment setup needed; the downside is that it cannot capture dynamic imports (such as __import__() or importlib) or conditional dependencies determined at runtime. In PLLM+'s pipeline, AST analysis is primarily used to quickly determine the target Python interpreter version range, narrowing the search space for subsequent steps.

LLM Fallback: Typed Error Classification and Dual Agents

In the LLM fallback stage, PLLM+ doesn't simply throw errors at the model. It introduces "typed error classification" to first categorize the failure reason, then performs repairs through a Proposer/Critic dual-agent collaboration. The Proposer generates a repair plan, while the Critic reviews and challenges it — this adversarial structure helps improve the reliability of repairs.

This design reflects a pragmatic engineering judgment: while large language models are powerful, they may not offer the best cost-effectiveness as a first choice for tasks like dependency resolution, where there is substantial reusable historical knowledge.

The Proposer/Critic dual-agent architecture draws from the Multi-Agent Debate research paradigm. The core insight is that a single LLM often exhibits "self-confirmation bias" when self-verifying, tending to defend its own output rather than critically examine it. By introducing an independent Critic role, the Proposer generates a repair plan, the Critic raises objections from different perspectives (such as version compatibility conflicts or missing transitive dependencies), and the Proposer revises accordingly — forming an iterative loop until the two reach consensus or the retry limit is exceeded. This structure has been shown to effectively improve output quality in tasks like code generation and mathematical reasoning, and is particularly well-suited to dependency repair, where answers can be objectively verified (whether execution succeeds), since the ultimate "arbiter" is the actual execution result rather than the model's self-assessment.

Empirical Results: Effectiveness and Cost

The research team evaluated PLLM+ on the HG2.9K benchmark, which contains 2,891 code snippets with dependency failures. The results are fairly straightforward:

Repair success rate: PLLM+ resolved 1,500 snippets, while the baseline method PLLM only resolved 1,169 — an improvement of approximately 28%;
Runtime efficiency: Average processing time per snippet dropped from 368.7 seconds to 71.8 seconds, a speedup of more than 5×.

Doing more with less time — this is an impressive system design result, and it validates the value of the "deterministic first, LLM second" strategy.

A Telling Finding: LLM Contributed Only 5 Fixes

The data contains a detail worth dwelling on. Of the 1,500 successful repairs, 1,495 came from configuration replays from the solution database, while the LLM fallback contributed only 5 additional fixes.

This lopsided ratio sends a clear signal: in this benchmark setting, deterministically reusing previously validated dependency configurations is a simple and highly effective strategy. Many dependency problems are fundamentally recurring — someone has already stepped on these landmines in the past and found the correct configuration, and directly replaying those answers is far faster and more accurate than having a model reason through them from scratch.

Of course, this finding deserves nuanced interpretation. The database replay works so well largely because the snippets in the HG2.9K benchmark come heavily from competitions with accompanying solution databases — in other words, this is an idealized scenario with "pre-existing answers." In real-world open-source projects without a ready-made solution library, the relative contribution of LLM-based repair would likely rise significantly.

The compositional background of the HG2.9K benchmark is critical to understanding this result. The code snippets in this dataset come largely from competitive programming platforms (such as Kaggle and HackerRank), which share several common characteristics: relatively standardized dependencies, libraries concentrated in the data science and algorithmic competition stack (numpy, pandas, scikit-learn, etc.), and platform-provided solutions that typically include complete runtime environment documentation. This means "configuration replay" is essentially searching within a near-closed, known solution space, yielding a naturally high hit rate. If the benchmark were instead drawn from arbitrary historical GitHub commits or code accompanying academic papers — where dependency diversity and scarcity are significantly higher — the configuration database coverage would drop substantially, and LLM's marginal contribution would likely be far more prominent.

Implications for Engineering Practice

The significance of PLLM+ goes beyond a higher benchmark score — it offers a transferable architectural philosophy:

Put knowledge reuse before generation. For highly repetitive, experience-accumulating problems like dependency resolution and configuration repair, first build a reliable library of historically successful configurations, use deterministic replay to handle the majority of common cases, and reserve large language models for long-tail, rare, and difficult edge cases. This layered design controls costs while improving overall accuracy.

For teams building AI-assisted development tools, this is a practical reminder: LLMs shouldn't be a universal hammer. Identifying which stages are suited to deterministic methods and which genuinely require model reasoning is the key judgment in system design.

Conclusion

Python dependency hell is unlikely to be fully cured anytime soon, but PLLM+ demonstrates a clear path toward relief — use cheap methods to solve most problems, and save expensive intelligence for the truly difficult minority. While its experimental results carry the particular coloring of the benchmark scenario, the design philosophy of "replay first, LLM as fallback" offers genuine lessons for broader automated repair and code engineering tasks.