Dependabot is running now, but only github-actions are kept updated, see ./.github/dependabot.yml. I've thought of extending it to tools.

EDIT: I don't know if specific files can be added to the list kept updated, but that would be convenient.

I'll note that there's a number of CI jobs that use unpinned test and build dependencies, so we're not missing any coverage.

Pinning everything is an option, but we're losing coverage of different versions of test dependencies at that point, so I'm not sure that that's actually a good thing. Or do we have failures due to new versions of dependencies too often?

If there's a need to pin everything, there's multiple ways of doing it: manual pinning, requirements files, or relying more on conda lock files like scikit-learn does. I don't know how happy scikit-learn is with that approach, but given that our most important dependencies are non-Python ones (BLAS/LAPACK libraries, compilers) I think that has the potential to significantly improve our test coverage. So it's worth looking into that either way.

If there's no appetite for turning on dependabot again, would a PR that updates the test dependencies be OK?

A PR for that is always welcome. My opinion is that Dependabot's maintainers have proven themselves to be utterly untrustworthy (it's really really not okay to ignore a major spam issue for 3 years) and that the Dependabot PRs are low-value noise mostly. So I'd much prefer not to re-enable Dependabot.

I mostly enabled dependabot to improve our security score, but it could also increase the danger of new upstream bugs. It has been useful a few times when there have been upstream fixes, in particular for rtools and changes in choco. Chasing down bugs and fixes is a bit easier with dependabot tracking our dependencies.