Enable caching by default to help PyPI

[hugovk]

I see caching is disabled by default (except for self-hosted runners).

What are the reasons for not enabling by default?

Nearly 30% of PyPI's downloads come from CIs (via BigQuery). Given 47.1 billion total downloads per month (via PyPI Stats), at least 13.8 billion downloads/month come from CIs.

Last month, PyPI used 105.5 PB bandwidth, which at list price would be around $12.5 million per month (via PyPA Discord). Fastly very generously gives PyPI a 100% discount on their bill.

At PyCon US this year, Fastly said over 10 years, they have served 4,682.1 billion requests and 2.41 exabytes of data:

If astral-sh/setup-uv enabled caching by default, this would significantly help ease the load on PyPI and Fastly, plus it can speed up runs by several minutes.

[eifinger]

I will add a more thourough answer soon but als a short teaser on why the default is currently disabled:

1. The other setup-x actions also default to disabling the cache
2. Each repo can only have 10GB of cached artifacts and will evict the oldest caches when this is exceeded. This might be unwanted behavior for some users.
3. I am not entirely sure if the cache counts towards the billed artifacts usage. If so this action would by default incur more costs than expected on private repos.

[eifinger]

4. It would be a performance penalty for self-hosted runners on default

[eifinger]

In a feature release caching will be automatically enabled on Github hosted runners.

I think this strikes a good balance between the arguments outlined so far.

[xmatthias]

@eifinger wouldn't you need to set prune-cache: false too to actually reduce load on pypi?

In my understanding of that setting (which defaults to true btw) - only locally built wheels will be cached - while wheels downloaded from pypi will be pruned - resulting in an empty cache if all packages had wheels on pypi.

Automatically, this will then do not much to reduce the load on pypi / fastlify ...