chore: implement dependency cooldowns in more areas

[agriyakhetarpal]

I was wondering (read: shower-thinking :P) about how dependency cooldowns could have merit in other moving parts of our update machinery besides Dependabot, where we have one set for 7 days. This PR adds 3-day dependency cooldowns to:

• constraints updates: using uv's --exclude-newer
• PBS: pretty easy, since this is all through GitHub releases
• virtualenv, in the same vein
• Node.js, through https://nodejs.org/dist/index.json, which has a date field per release entry. We can argue it's a bit overkill, but I thought maybe it's better to be consistent with the other scripts.
• Python (update_pythons.py). There are some differences:
  • PyPy, CPython, and CPythonIOS are straightforward
  • Maven is a bit of a hack to me
  • NuGet is mostly based on how Dependabot and the Microsoft SDK does it
  • Pyodide (I've kept cooldowns for this).

AI disclosure: I used Claude Code in Plan mode on Haiku 4.5 to navigate the Maven and NuGet changes, ping the package repositories, and explore their webpage structure (changes dropped now). It gave me decent working code that I refined further.

There is a CIBW_IGNORE_COOLDOWN environment variable to ignore this. Our update-dependencies workflow will set this to false, but I've also added an input for manual triggers. This way, ignoring the cooldown will remain a conscious choice on our part.

I left the Docker update script as is. I can't understand what we'll do there since it only resolves the current digest of the latest tag. There's no "release date" concept there.

TODO, but doesn't necessarily need to block this PR:

• Implement a date field for Pyodide xbuildenvs so that we and other downstream projects needing it can inspect it, and thus we can implement a cooldown for it here. (Done in Add publish dates for cross build environments pyodide/pyodide#6248).

[Copilot]

Pull request overview

Copilot reviewed 5 out of 10 changed files in this pull request and generated 3 comments.

[henryiii]

As I've said, I don't like this. We are already slow in getting updates to users. CPython 3.15.0b1 comes out today; I don't want to wait a week before we have a chance to add it to our main branch! The other dependencies might need to be making releases to support 3.15.0b1 too, we don't want to force old versions that are less likely to be compatible. To support stable free-threading ABI, for example, you need pip and build versions that are around a week old today. Our main branch doesn't need to be behind by a week. There's generally a bit of a delay anyway before we make a release, so anyone using our released versions gets older versions already.

A day or so might make sense because we have to wait on manylinux, so we generally updates a little sooner than manylinux, so a small delay would help us align better, possibly.

Also, CPython released 3.14.5rc1 with about a week window, so anyone with a week cooldown will miss CPython's RC entirely, invalidating the main reason to do an RC.

If users want a cooldown, they should apply it to cibulidwheel, not us on our pinned dependencies. If they do apply it, and we do too, it compounds, as well.

I believe a much higher reward change (that doesn't have drawbacks, like interfering with shipping new Python releases) would be to add SHA checks for our Python downloads. That would protect against a much

[agriyakhetarpal]

Thanks for your feedback about this @henryiii, I didn't know many of these aspects (and may have missed where you last spoke about it)! I agree and will rethink all Python and PBS-related upgrades, they're not helpful especially if we miss deadlines. I would want us to cascade safer dependencies to our users, but I also want to note that my focus with such a PR is to protect cibuildwheel itself.

A day or two might make sense, but the fact that our dependency updates run once a week anyway makes things a bit messy. I'll change to it for Python/PBS and try...

Would you suggest that the 7-day cooldowns added to virtualenv and the build constraints, being dependencies of Python at a fundamentally shallower level, are still useful and could be kept?

Yes, SHA-pinning is also within my plans – I am happy to start looking at that, and Sigstore attestation verification too.

[joerick]

Broadly agree with @henryiii. But, I think there might be some merit to the cooldown when it comes to our constraint pinning. There are lots of requirements there (especially for Pyodide), and that probably represents the largest risk in terms of supply chain attacks. I'd be less worried about the Python versions themselves - if they're compromised, we as an ecosystem have bigger problems :).

Would maybe 2-3 days be a reasonable value here? Bearing in mind that it's pretty unusual that we'd merge a fresh Update Dependencies PR and immediately merge.

The other bits I'm less bothered about, personally. I'd say maybe not worth the extra complexity? Virtualenv is basically a version pin, so I can see the argument for that. For the rest, I'd be fine to leave without a cooldown I think.

[agriyakhetarpal]

I think a value of 3 days works. I guess the jury has decided then :) I'll drop the Python-related changes here but keep the rest. Thanks!