You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All in all, I'm not really a big fan of a lock file. We can synchronize to a single unified developer experience, but it won't change the issues users face.
I prefer that we as maintainers experience these issues in environments and during review.
@mattijn I've thought some more about this and think I have an idea that gives us the benefits of both
GitHub Action scheduled at some interval (e.g. weekly, monthly) that adds a PR upgrading our lock file and running the test suite
If our CI is green, it could merge to main without review
Otherwise, it should block subsequent runs and require a maintainer to address the issues in that PR to merge
So we get the failures isolated to a single branch (one less concern for new contributors).
But we also continue to know well-ahead of release that we may have a dependency issue (preserving the current feedback loop).
I would split this into another issue to plan out how we'd achieve this.
However, after reading these I feel convinced we have options:
Originally posted by @dangotbanned in #3723 (comment)
@mattijn I've thought some more about this and think I have an idea that gives us the benefits of both
main
without reviewSo we get the failures isolated to a single branch (one less concern for new contributors).
But we also continue to know well-ahead of release that we may have a dependency issue (preserving the current feedback loop).
I would split this into another issue to plan out how we'd achieve this.
However, after reading these I feel convinced we have options:
uv
uv
uv lock --upgrade
The text was updated successfully, but these errors were encountered: