Automatically re-generate lockfiles if requirements changed in CI

[sureshjoshi]

We’ve discussed this before, but I think we always overcomplicated it re: dependabot.

I think a more generalized solution is that, in any CI run, if one of our python requirements files has been touched, we should re-generate the lockfiles and either a) commit, or b) fail out.

For dependabot, we should commit for sure - for non-dependabot, I’m a little less certain.

I can add this functionality as I start unwrapping the generate-workflows into separate functions.

[cburroughs]

Isn't this what the (very fiddly) lockfile metadata already does?

[sureshjoshi]

I don't think so, I re-titled it to better describe my intent. This is something I'm looking at in a few repos, and I'm debating if it should be a lint error of some sort.

This specific issue is mostly to let us fully use Dependabot to update lockfiles (once the remaining breaking changes are done). As in, we would run generate-lockfiles in CI, and commit that code for review in the dependabot PR (which is also why I want to get that Pip cooldown thing working too).

Our dependencies fall out of date fast, and they can be fully automated with a bit more TLC. I'm going to be working on re-jigging our actions similar to scie-pants, and this is a step I might want to add.