Python, Gradle and Maven caches: what you can safely delete

Python and JVM projects don’t have one giant node_modules. They have a handful of caches and build folders that are easy to overlook. Some are disposable, and at least one will cost you an afternoon if you delete it by mistake.

Python

The tool caches can grow surprisingly large on big codebases, with .mypy_cache the usual leader. Each tool can clear its own:

pytest --cache-clear

Gigaflush cleans .pytest_cache, .mypy_cache and .ruff_cache when they sit next to a pyproject.toml, setup.py or requirements.txt. It doesn’t remove __pycache__ today. Those are usually small and Python recreates them constantly.

Gradle

Gradle uses two kinds of storage, and the difference matters:

• Project .gradle/ sits next to build.gradle or settings.gradle. It holds per-project caches and file hashes, and is safe to delete when no build is running.
• Project build/ holds compiled classes, test results and APKs. ./gradlew clean removes it.
• Global ~/.gradle/ holds downloaded dependencies and wrapper distributions for every project. Deleting it is safe but forces a large re-download.

./gradlew clean

Gigaflush removes the project-local .gradle folder (when a Gradle build file is beside it) and deliberately never touches the global ~/.gradle.

Maven

• target/ next to pom.xml holds compiled classes and packaged JARs. mvn clean deletes it, and it’s safe.
• ~/.m2/repository is the local repository of every dependency you’ve downloaded. Safe to delete in theory, but you’ll re-download everything, and any artifacts you installed locally with mvn install are gone.

mvn clean

Gigaflush lists a target folder as Maven only when pom.xml is next to it, which keeps it from confusing Maven output with Rust’s target.

The short version

Tool caches and build output: delete freely. Virtual environments and global dependency caches: delete only on purpose. For the “delete freely” pile across all your projects at once, Gigaflush does it in one scan.