Maintainers usually find out a dependency is dead when something breaks. DepExit finds the risky ones up front, asks Gemma 4 for a replacement plan for each, and then refuses to trust the plan until it has applied it to an isolated copy, reinstalled everything and run the tests. Each dependency gets a Dependency Exit Capsule: a JSON record, a readable Markdown page and a patch. Every fact in it is tagged OBSERVED, MEASURED, AI-SUGGESTED or AI · VERIFIED, so you can see which claims came from files, which came from running code, and which are only the model's suggestion.
Who would pay: freelancers and small agencies who take on neglected Python codebases, and small teams who inherited one. Today that audit means a day or two of reading changelogs and guessing. DepExit turns it into a 13-minute run that produces a report you can hand to a client and a patch you can review. A wrong migration in a healthy project is worse than none, so the part worth paying for is that nothing is claimed as fixed until it has been run.
A complete run on the organizer's LinkWatch repo is committed in examples/linkwatch-run/. Open report.html after cloning, or read SUMMARY.md on GitHub. It was produced on 15 October 2026 with gemma-4-31b-it through the Gemini API and took 13 minutes.
Measure
Result
Dependencies analysed
16
At risk
10
Gemma 4 plans verified by execution
10 of 10
Tests before
9 of 10 passing, 1 warning
All verified plans applied together
23 of 23 passing (10 original + 13 written by Gemma), 0 warnings
Evidence-first dependency exit planning, with Gemma 4 proposing and execution deciding.
Hacktoberfest Hack Day Mumbai × ISTE KJSSE 2026 · Track 1: Gemma 4 · Dependency Resilience · Team 404_TeamNotFound
DepExit points at a Python repository, finds the dependencies that put it at risk, asks Gemma 4 how to get out of each one, and then refuses to believe the answer until it has applied the change to an isolated copy, reinstalled everything, and run the tests. What comes out is a Dependency Exit Capsule for every dependency: a JSON record, a readable Markdown page and a patch, in which every single fact is tagged with where it came from.
Tag
Meaning
OBSERVED
Read from the repository's files or from PyPI and GitHub metadata. Nothing was executed.
MEASURED
Produced by running something: an install, an import, the test suite.
The rule behind the design is that Gemma proposes and execution decides.
Deterministic code does the seeing. It parses requirements*.txt and pyproject.toml, walks every file with ast to find imports, private-API use and monkeypatches, installs the project in a clean virtual environment, imports each package on its own, runs pytest, and pulls release history from PyPI and GitHub.
Gemma 4 does the thinking. It receives only the evidence DepExit collected and the exact files involved, and returns a replacement decision, code edits, requirement changes and small tests that capture the behaviour the repo relies on. I used gemma-4-31b-it through the Gemini API, with an automatic fallback to gemma-4-26b-a4b-it. Local inference through Ollama is supported too.
Deterministic code judges. It applies the plan to a fresh copy and runs the original tests plus Gemma's own tests against both the original dependency and the replacement. A plan counts as verified only if every risk indicator is gone, nothing regressed, and the old package is no longer referenced. If it fails, the concrete failure output goes back to Gemma for one corrected attempt.
Gemma never decides risk, never grades its own work, and is never the source of an OBSERVED or MEASURED field. Packages it proposes are checked against PyPI, and every prompt and raw response is saved next to the capsule.
An earlier run marked requests as verified even though Gemma's reply had been truncated and nothing was changed. I found it by reading our own capsule, then fixed the parser and added plan validation and per-indicator re-checks. The committed run is the fixed one. I also ran DepExit with no AI on an unrelated project, jazzband/prettytable (337 tests), which exposed four layout bugs that I fixed the same day.
Why Does Open Innovation Matter?
A tool that audits other people's code has to be trustworthy, and open models make that checkable.
Auditable. Gemma 4's weights are Apache 2.0, and DepExit saves every prompt and raw response. A capsule is a replayable record rather than a black-box answer, and depexit replay re-verifies a saved plan later without calling any model.
Private when it needs to be. The people who would pay for this often can't send client code to a closed API. DepExit can run against a local Gemma 4 through Ollama, so the code stays on the machine. [Keep this only if you complete the Ollama run. Otherwise write "can run locally" and name the tradeoff.]
No lock-in. There are no paid services, and switching the model is a flag (--ai google or --ai ollama), not a rewrite.
My First User
My first user tried DepExit on a Python project with outdated dependencies and found it useful for identifying at-risk packages and understanding potential replacements. They particularly liked that DepExit didn't just suggest migrations using AI but actually tested them and provided evidence of whether they worked.
Their feedback was that the detailed reports made dependency issues easier to understand, although a simpler summary of the recommended changes would make the tool even more convenient. They would consider using DepExit for maintaining legacy projects and suggested adding clearer migration priorities to help developers decide what to fix first.
drive.google.com
