Skip to content
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

Open
neutrinoceros opened this issue Sep 7, 2023 · 5 comments
Labels
question Further information is requested

Comments

@neutrinoceros
Copy link
Collaborator

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.

@neutrinoceros neutrinoceros added the question Further information is requested label Sep 7, 2023
@neutrinoceros
Copy link
Collaborator Author

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.
I'm game to do it that way too.
How about it, @glesur ?

@glesur
Copy link
Contributor

glesur commented Oct 12, 2024

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 :

  • how much work (ie messing around with sphinx dependencies) these automatic PR will imply (there are quite a few hacks hidden in the doc generation since the api is documented through doxygen which is then parsed by sphinx)
  • how this is going to work with readthedocs (where the doc is actually published).

Do you have any experience on this?

@neutrinoceros
Copy link
Collaborator Author

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.

But I'm not 100% sure to know :

  • how much work (ie messing around with sphinx dependencies) these automatic PR will imply (there are quite a few hacks hidden in the doc generation since the api is documented through doxygen which is then parsed by sphinx)

Hard to tell for sure before we give it a go but for what it's worth:

  • on the slowest schedule, dependabot allows for a single PR per month (it's still too frequent for my typical needs, but it is what it is)
  • as with all things, fixing small problems regularly might be a lot easier than solving a giant mess once in a blue moon (but I'm taking a bet here)
  • how this is going to work with readthedocs (where the doc is actually published).

this part is actually trivial, dare I say already solved: readthedocs uses this requirement file already
https://github.com/idefix-code/idefix/blame/2f15373cb58387d67a91bd1e289416aab4813657/.readthedocs.yaml#L29
(or maybe I'm missing the point ?)

@glesur
Copy link
Contributor

glesur commented Oct 14, 2024

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

@neutrinoceros
Copy link
Collaborator Author

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) !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants