Given the lack of response on the mailing list, let me retry this in issue form

Reposting from https://mail.python.org/archives/list/[email protected]/thread/ALJABLQADLBEXB7MZKXI2F5OAUT4UN6Y/

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 . 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 ?