Hi everyone
As you may have noticed, my personal availability to work on compatibility issues for yt has been decreasing. Meanwhile, [dependency hell keeps breaking loose](https://github.com/yt-project/yt/issues/5301) . I'm growing wary of this kind of "implicit upgrades" constantly breaking CI at unpredictable (and inconvenient) times, so I would like to propose a long-term solution, that will help isolating them so they:
- do not incapacitate normal CI
- can be dealt with on our on schedule
- (but are still automatically detected)
Basically the solution is to build two separate CI modes:
- stable (locked): this is the regular CI that runs on every PR. It should be reliable and only break when *our* code breaks.
- unstable (unlocked): this is akin to our "bleeding-edge" CI now, but instead of just running against a couple, hand-picked dependencies at pre-release stage, it's role would be expanded to running against all the latest dependencies (including potentially broken ones), and mimic what users get from running `pip install yt` at a given time.
"locking" test environments means:
- skip dynamic dependency resolution on stable CI, using a static lockfile instead (think of it as a known-good record of yt's dependency tree)
- periodically upgrade the lock's content with automated PRs. Points of failure will be isolated to *these* PRs (and bleeding-edge CI).
I know how to implement all of this with uv, but I also know that some may feel concerned about changing the testing strategy, so I'd like to open a discussion first. Are there any strong objections or concerns I should try to address first ?
Cheers
Clément
