Pin dependencies version in CI with lock files with a bot that auto-updates the lockfiles

### Motivation

- avoid CI breakage due to dependencies updates (recent examples: setuptools update, pytest7 update, coverage 6.3 update, very likely others ...)
- avoid painful debugging when a breakage happens to figure out what is the cause of the problem and generally end up after some time that a dependency has changed
- avoid breaking everyone PRs which is confusing for contributers

### Ideas for implementation

- have environment.yml files for each build rather than versions defined in azure/Circle .yml (for the build using build, we can either use  poetry or conda-lock is supposed to support pip section in the environment.yml although I have not managed to get it to work yet)
- have a script using [conda-lock](https://github.com/conda-incubator/conda-lock) to regenerates conda lock files for each build based on their environment.yml
- have a bot that runs this script updates the lock files and creates a PR, it seems like using an approach using GH action like  Hypothesis does could work:
  https://github.com/HypothesisWorks/hypothesis/commit/c96bbc86efbaa46a78bbb075a36869734dde76b9.
- Have this PR merged if CI passes
- only one PR opened at a time to avoid generating many PRs with the same diff. If there is already an open PR (based on a github label for example), push -f  to the PR branch

### Where to start

I'll probably try out this idea on one build first (e.g. one using conda-forge) to test it out, see how that works, and go from there.

cc @thomasjpfan in case you have some thoughs about this or you have already started working on something similar

### Rejected alternatives

In an ideal workd we would "just" use Dependabot but [it can spam forks](https://github.com/dependabot/dependabot-core/issues/2804) with PRs. Numpy has given up on it see for example [this](https://twitter.com/ralfgommers/status/1457023221841149955)

COMMENT:
Thanks a lot for your inputs!

> I wouldn't go with lock files just yet since they are platform specific.

Just to be clear, in my mind the lock files would be generated from their respective environment file (e.g. with [conda-lock](https://github.com/conda-incubator/conda-lock)). This is OK to be platform-specific since the lock files would only be used in the CI. Users would use environment.yml file as you mention.

> GitHub actions to bump the versions.

How do you see the environment.yml update working? I guess if we don't use lock files we would need to write a custom script, which does not seem that straightforward to me.

As an aside, I think recent CI breakages are not related to "real" dependencies (numpy, scipy, etc ... actually we probably catch some/most of them in our scipy-dev build) but to other packages we use for the CI (pytest, coverage, setuptools). Lock files would allow to lock all the versions for these packages.

> Edit: Dependabot would be preferred but https://github.com/dependabot/dependabot-core/issues/2804 with PRs.

Yep indeed I have added this in the "rejected alternative" in my top post. Ralf Gommers' [Twitter post](https://twitter.com/ralfgommers/status/1457023221841149955) is pretty clear about this.

Labels: Build / CI