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
_______________________________________________
yt-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3//lists/yt-dev.python.org
Member address: [email protected]
