-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Update uv_build version automatically #1899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update uv_build version automatically #1899
Conversation
In pypa#1880, the concern was raised that the uv_build upper bound in the docs will go stale. This PR adds a GitHub Actions workflow that automatically updates the version daily with the latest uv(-build) version. I tested this change on my fork, but I unfortunately can't test this in pypa/packaging.python.org itself.
webknjaz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for looking into this. I've pointed out a few problems and requests below.
|
OTOH, I'd probably prefer this data extraction to be an in-tree Sphinx extension. It could get fresh versions on build and make use of Sphinx's built-in caching mechanism. |
Co-authored-by: 🇺🇦 Sviatoslav Sydorenko (Святослав Сидоренко) <[email protected]>
I can contribute a GitHub Actions workflow, but I can't contribute a Sphinx extension. To me, the workflow has the advantage that it allow explicit review and doesn't need an external service on build. |
Co-authored-by: Alyssa Coghlan <[email protected]>
|
Hi, I wanted to chech in on this PR again. Is it realistic to have this PR merged with GitHub Actions workflow, or would we need a Sphinx extension? |
I'd prefer an extension because it'd run on rebuilds and would reduce the PR noise. It's not as reviewable but has a chance of actually updating the published content more often than PRs that would sit in the repo for months. |
I'll go ahead and take responsibility for these PRs -- I agree with your rationale about a Sphinx extension in the long term, but I'm okay with taking on the review responsibility/load for this in the medium term as a measure of expedience 🙂 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @konstin! I'm going to do a last pass on this tonight, but otherwise this LGTM. I'll also see about the link check failure then.
(For posterity, I'll record here as well that I'll take ownership of triaging these automated PRs as they come in.)
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
webknjaz
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
![]()
In #1880, the concern was raised that the uv_build upper bound in the docs will go stale. This PR adds a GitHub Actions workflow that automatically updates the version daily with the latest uv(-build) version.
I tested this change on my fork, but I unfortunately can't test this in pypa/packaging.python.org itself. You can see an example pull request created by this action in konstin#2.
📚 Documentation preview 📚: https://python-packaging-user-guide--1899.org.readthedocs.build/en/1899/