Repository navigation
Automatically clean up cached downloads #368
Description
Activity
Put the emphasis on "cache" rather than "temporary" and it does make more sense for it to be in our own directory (still in
AppData\Local, just like defaultTemp). But the distinction is quite small.It's a little more reliable to minimise the directories that we read and write to - maybe 0.1%, but that's only a few thousand users 😉 - in case people (or their administrators) have redirected, re-permissioned, or are actively scanning TEMP. Some code/malware/virus scanners are much more aggressive when executable files appear in TEMP, so there's an added risk that our installs would fail that we can avoid by using a separate directory.
Note that these are all silly reasons, but the reality is that they're real reasons nonetheless, and our aim is to maximise reliability. If a download to our own directory fails for permissions/scanning/volume/etc. reasons, then so would the extract and launch, whereas separating the two steps only makes it more likely, since there are now separate conditions for each step.
We also might reuse the file (for a repair/reinstall), and though we usually have the original hash from the index, that isn't strictly required. In that case, blindly extracting a file from TEMP based on filename is ever so slightly worse than doing it from our own directory.
Cleaning up old packages over time is something we could consider doing, though. Maybe an extra step after installing to delete anything from the downloads directory that's older than 30 days? It hasn't become an issue yet that I've heard of.
(Users/admins can of course change their config use use actual
%TEMP%for the downloads directory if they want. That's why it's configurable. From our POV though, as a default, it's slightly worse in a way that isn't worth the risk.)Reacted by Bill StewartThanks for the explanation; this is all reasonable and makes good sense.
Cleaning up old packages over time is something we could consider doing, though. Maybe an extra step after installing to delete anything from the downloads directory that's older than 30 days?
My suggestion is to do something like what browsers do: Have a limit on the number of days or a limit on the amount of disk space used.
It hasn't become an issue yet that I've heard of.
My $0.02 (which, admittedly, is not worth much) is that good practice is to (safely) clean up things under one's purview (as in the aforementioned case of browsers).
It all gets cleaned up with
py uninstall --purge, which is how we recommend cleaning up everything we're responsible for. There's just no incremental version of it, other than manually going in and deleting them by hand.It all gets cleaned up with py uninstall --purge, which is how we recommend cleaning up everything we're responsible for.
Right, but that's going to remove all installed runtimes, isn't it, not just the download cache.
Yeah, it's more a case of responsibly cleaning up after ourselves than doing it incrementally. Like I said, the ideal would be to clean up old downloads automatically as part of doing an install, but it hasn't yet presented as a problem that we don't (compared to, say, not properly encoding credentials, which is a problem that we recently fixed).
but it hasn't yet presented as a problem that we don't...
Don't what? (Sorry, not understanding what you mean.)
Ah, you mean nobody's complained that it's a problem that downloads aren't cleaned up automatically.
Well, consider this the first--well, not a complaint, as such, but rather an observation.
Yeah, nobody has complained yet, and they still haven't ;)
There are many thousands of observations made, and no reasonable way to fix them all, and certainly no way to prioritise them all with the volunteer time that we have. Even for things that are obviously problems, we like to hear what the real impact is, as it usually helps us understand our users better than when something is presented as a problem in abstract.
If it's something you'd like to see changed, feel free to create a PR. Most of PyManager is written in Python, and probably the biggest challenge here is that we use a stripped down pathlib module (for faster load) that might be missing the stat function needed.
Otherwise, I'll leave this as a suggested enhancement until someone has the time/motivation to work on it.
- changed the title
[-]Why download_dir not in %TEMP%?[/-][+]Automatically clean up cached downloads[/+]on Jun 15, 2026
Background
According to the documentation, the
download_dirdirectory "is a temporary cache, and can be cleaned up from time to time."Details
If the
download_dirdirectory is a temporary cache, wouldn't it make sense for the default to be%TEMP%\Python(or something similar), rather than a subdirectory of theglobal_dirdirectory?Why?
Files in
%TEMP%should be assumed to be temporary (hence the name), so wouldn't it make sense to put temporary downloads there?Files in
%TEMP%are, I believe, subject to the Windows automatic "clean up temporary files" feature, aren't they? In this way, old downloads would get cleaned up automatically, wouldn't they? (I'm not an expert on this feature, so I may be all wet here.)I'm new to this project, so I'm sure others will set me straight if I'm way off here...