-
Notifications
You must be signed in to change notification settings - Fork 19
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
DOC: use GitHub's dependabot to manage doc/python_requirements.txt ? #191
Comments
Hey, I'm back from vacation ! another solution would be to pin the entire environment, including indirect dependencies. Still not 100% future proof (it could reduce portability or make it harder to upgrade to a newer Python), but it's a pretty cheap one-time cost. |
A long-standing issue...! I think the best solution is actually the first one, as it allows us to follow the inevitable evolution of python and sphinx packages. But I'm not 100% sure to know :
Do you have any experience on this? |
I do ! This is a widely spread strategy for keeping Python requirement files updated and I've used it on many projects big and small.
Hard to tell for sure before we give it a go but for what it's worth:
this part is actually trivial, dare I say already solved: readthedocs uses this requirement file already |
My point is that readthedocs might just break silently, since the build success (or not) of the doc by readthedocs is not a CI. We can give it a go... |
It should be possible to configure readthedocs to build in CI specifically when this file is updated. If not, it should be easy (albeit a bit wasteful) to add a custom GitHub Action job that mimicks it. I'll look it up (sometimes soon) ! |
Question
While it's good practice to pin down exact requirements for documentation builds in a requirement file (as we do now), in my experience this tends to not be future-proof as indirect dependencies release incompatible versions and break builds.
A common solution is to use GitHub's dependabot service to periodically issue update PRs so the requirements do not rot away into inevitable breakage.
This would also necessitate integrating test builds into the CI.
I'm happy to do all of that when I'm back from vacation.
The text was updated successfully, but these errors were encountered: