What Zero Dependencies Actually Meant for RepoX-Ray

## What Zero Dependencies Actually Meant for RepoX-Ray

When we started building RepoX-Ray for Zero Dependency 2026, I thought zero dependency mainly meant one thing:

Don't install any packages.

I quickly realized it meant much more than that.

RepoX-Ray is a CLI tool that scans repositories for security, dependency, Git, configuration, and code-quality issues. Normally, we would probably reach for packages like GitPython, Click, Pydantic, or pytest.

Instead, we had to ask:

“What can Python's standard library do for us?”

Replacing packages with the standard library

For Git operations, we used subprocess instead of GitPython.

For the CLI, we used argparse instead of Click or Typer.

For data models, we used dataclasses instead of Pydantic.

For testing, we used unittest instead of pytest.

For file and pattern handling, we used pathlib and fnmatch.

None of these replacements were impossible. The difficult part was putting the pieces together ourselves.

The standard-library feature I didn't expect

One of the most useful discoveries was Python's ast module.

Instead of searching Python files as plain text, ast lets us inspect their actual syntax structure. We used this for import analysis, which made the analyzer much more useful than simple text matching.

It made me realize that the Python standard library has tools I had never really considered before.

What was harder than the documentation made it look

The hardest part was Git history analysis.

Checking whether a sensitive file exists right now is relatively straightforward.

But what if the file was deleted?

For example, a .env file could be committed, deleted later, and completely disappear from the current working directory. The secret could still be recovered from an old Git commit.

RepoX-Ray therefore checks Git history for deleted sensitive files and possible secrets.

We had to use subprocess to run Git commands and then correctly interpret their output. This was much more involved than simply calling a Git library.

What I learned

The biggest lesson was that zero dependency doesn't mean zero effort.

A package often hides many small implementation details behind a simple API. When you remove that package, you start seeing those details yourself.

But that was also the most valuable part of the challenge.

Instead of immediately thinking:

“Which package should we install?”

we started thinking:

“What does this package actually do, and can the standard library give us the building blocks?”

RepoX-Ray ended up with an empty requirements.txt, 47 passing automated tests, Git-history analysis, cross-file checks, and a repository health score — all without third-party runtime packages.

That is what zero dependency actually meant for us.

Comments

[Baptiste Le Bouquin]

The ast discovery is underrated. I did a similar exercise on a CLI scanner and parsing imports via ast instead of regex-on-text caught things like conditional imports and try/except fallbacks that text matching silently miscounted.

Curious how you handled the edge cases where the stdlib substitute is genuinely worse — argparse gets painful fast once you want nested subcommands with shared options, and unittest vs pytest for parameterized tests is a real ergonomics drop. Did you accept the worse DX, or build a thin layer on top (which arguably reintroduces a dependency, just an internal one)?