Cache

Short answer: PragyaLint keeps no on-disk analysis cache in the current release. Every run re-discovers your files and re-parses them. This page explains why, what actually controls a scan's cost, and how to keep re-runs fast.

Is there a cache?

No. PragyaLint does not write any persistent state (no pragyalint.cache, no build directory, nothing hidden in __pycache__). Each invocation:

  1. Walks the project tree looking for matching files.
  2. Parses every matching file with the standard-library ast module.
  3. Builds the module graph and runs the requested rules, all in memory.

That's deliberate:

What actually affects run time

FactorEffect
Number and size of filesParsing dominates the scan; more code means a slower pass.
--includeRestricts analysis to files under the listed paths — the single biggest lever.
--ignoreSkips generated/templated/vendored directories entirely.
--rulesFewer rules means fewer traversal passes over the graph.
--extensionsLimits which files are parsed at all.

How to keep re-scans fast today

# Narrow the scan to your source tree
pragyalint --include src

# Skip generated and vendored code that'll never be dead
pragyalint --ignore "**/generated" --ignore "vendor/"

# CI: only the two highest-confidence, graph-only rules
pragyalint --rules unused_file unused_import --fail-on high

Re-running immediately after a scan is also cheap because the OS page cache still holds the source files — nothing about the analysis itself is cached, but the operating system caches the reads.

Busting the cache

There's nothing persistent to bust. If output ever looks stale, it's not a cache — re-run the command. A quick way to be sure you're analyzing what you think you are:

pragyalint -v   # prints every module and whether it's reachable (R) or dead (D)

Roadmap

A persistent incremental cache is a plausible future feature (skip re-parsing files that haven't changed). When one ships, this page will document how it's enabled, when it's invalidated, and how to clear it.