How to clear pip's cache on Mac without losing your venvs

If you’ve been searching for the pip clear cache command, let me just put you out of your search misery quickly — that command doesn't exist.

Pip is Python’s package installer, and it keeps cached copies of all the packages it downloads or builds. That’s obviously really useful when you’re reinstalling the same dependencies, but on a Mac, that cache, as you can imagine, is going to grow significantly.

The good news is that clearing pip’s cache is one of the safer developer cleanup wins. It doesn’t remove any of your installed packages or virtual environments; it just deletes files pip can download again later.

I’ll walk through the pip cache commands worth knowing, what’s safe to delete, and the other Python-related files probably using space on your Mac, too.

Pip clear cache: is it even a genuine command?

I just really want to save you time here, because no, pip clear cache isn't a valid command. It definitely sounds like it should be, which is probably why so many people search for it, but pip doesn’t use that wording.

The command you actually need is: pip cache purge

This clears up pip’s entire download and wheel cache. After running it, you’ll usually see a small report of the exact number of files removed.

That’s of course going to depend on how much pip has cached on your Mac.

I know just how tempting it is to jump straight into cache removal, and if your Mac’s running slow or storage is tight, or if your Python environment is just not working as smoothly as it normally does, I get the urgency, but before you purge everything, it’s worth understanding what pip has cached, how big that cache actually is, and where it lives on macOS.

That way, you know if pip is really the problem or just one small part of a bigger Python storage mess. That’s what I’ll cover next.

Check what’s in the cache first

Ok, so these commands are going to help you locate and understand your pip cache. Open Terminal and start with: pip cache info

This is going to show you your cache location and size, including pip’s package index cache and wheel cache.

Good to know: on macOS, pip usually stores this here: ~/Library/Caches/pip

For a quick size check on Mac, run: du -sh ~/Library/Caches/pip

If you want to see the cached packages and wheels themselves, use: pip cache list

Or narrow it down with a pattern: pip cache list requests

That way, you can see if pip is genuinely taking up space, or if it’s just one specific cached package that’s the real problem.

All the safe ways to clear cache

The commands are simple, but each one has a slightly different use case. Here are all the ones I think are worth knowing:

• To clear everything: pip cache purge

• If one package is causing problems, clear just that package instead: pip cache remove <package-name-or-glob>

• And if you want to install a package without adding anything new to the cache, use: pip install --no-cache-dir requests

Clearing pip’s cache is safe, but your next installs may be slightly slower while pip downloads fresh copies, so that’s worth keeping in mind.

When clearing the cache actually fixes something

Clearing pip’s cache isn’t just about storage; there are times when it can also fix weird install problems, or if pip keeps reusing a corrupted or stale cached wheel.

If it’s just one package that keeps failing, try removing specifically that package first with: pip cache remove <package> (replacing <package> with the actual package name). Then, you can test reinstalling it with: pip install requests

For any local Mac development, this is going to be usually pretty safe, but for CI/CD pipelines, I’d be a bit more cautious. A pip cache may be there deliberately to speed up builds, so blindly purging it can slow every run.

Is pip the only culprit?

Clearing your pip cache is a good start, but Python tooling has a little habit of scattering files across your Mac.

Old Conda environments can sit around long after you’ve stopped using them. Pyenv can keep multiple Python versions installed. Forgotten .venv folders can hide inside old project directories. Then there are __pycache__ folders, .pyc files, Poetry caches, uv caches, and Jupyter checkpoints and cache.

None of these are necessarily “bad” by default. They all exist to make Python faster or more convenient. But if you’ve been experimenting lots, or even switching tools, and working across lots of projects, then at some point they’re just going to add up.

Here are some more useful cleanup commands:

• conda clean --all

• poetry cache clear PyPI --all

• uv cache clean

• find . -name "__pycache__" -type d -exec rm -rf {} +

If you use several developer tools, CleanMyMac CLI can handle more of this from Terminal. Its clean dev command scans and clears cached data from pip, Poetry, and uv, plus Homebrew, npm, Docker, and a dozen others.

Install it with: brew install --cask macpaw/taps/cleanmymac-cli

Then run: cleanmymac clean dev

It shows what it found before deleting anything — deselect with Space, then press Return to confirm.

If you're clearing pip's cache because you're low on space, old virtual environments are usually where the real gigabytes are, especially in projects you've stopped working on. cleanmymac purge finds them, grouped by project. It preselects artifacts older than seven days, so check the list before you confirm. 

CleanMyMac CLI is in public beta, with the full command list available on GitHub.

If your Mac needs more of a general cleanup

If you think about it, dev caches are usually just one layer of a messy system. I know for me personally, I can also usually count on a buildup of general system junk, all my old logs, and all my forgotten downloads that pile up and just eat up space.

I’ve also been using the Cleanup feature from CleanMyMac to keep on top of things. You can test all features for seven days — get your free trial here.

Pip cache cleanup isn’t something you need to obsess over every week. It’s going to be more of a useful reset when installs start behaving weird, or your storage gets tight, or potentially if your Python setup has been through months of testing, rebuilding, and abandoned projects. The main thing is knowing the difference between cached files and the environments you actually work in.