Contributing fixes to revdeps
Closed this issue · 8 comments
It maybe worthwhile to help individual authors if they're stuck (possibly before sending any revdep emails to get a sense of possible package bugs, or possible after several to help those who are struggling).
Claim the package on the googlesheet by adding your Github user name to the "who" column. Then use the following code to get the package on to your computer in a form suitable for editing:
options(usethis.destdir = "~/revdeps/")
create_from_github("owner/repo")
pak::local_install_dev_deps()
pr_init("dplyr-1.0.0")
devtools::test()
devtools::check()
# Repeat until fixed
pr_push()
Once done, you'll need to delete the revdeps directory. But before you do that, make a list of all the packages, so you can (if you want to) clean up the forks you have made in your Github account
Should include some advice about creating a temporary library so you can throw it away afterwards.
This feels relevant to revdepcheck (the package). Yesterday I wished I could tell revdepcheck to get itself into position to do its thing on package A, then just STOP. And let me go there and explore package A with respect to the rather militant library setup of revdepcheck. Basically, allow my interactive troubleshooting to piggyback on some setup that is already being done by revdepcheck.
@jennybc that is a bit less relevant now that we're often doing checks in the cloud.
But if you see problems in the cloud, you will need to investigate some of them locally, right? It's a bit like the usual problem with CI. It can alert you to a problem but it's very difficult to understand and certain problems from arm's length like that.
@jennybc right, but then how does revdepcheck help? You really want the github source (not the CRAN tarball) and installing the needed packages is a single call to pak. I feel like I'm missing something.
Well, before you try to make a PR with a fix, you try to understand how your package is breaking the CRAN version of theirs.
I guess your single call to pak + the plan to recommend a temporary library is most of what I'm talking about. But I assume revdepcheck also makes sure that .libPaths() includes only this temporary library + system library. I perceive that what revdepcheck does re: temporary library + .libPaths() is exactly what you want when trying to find the problem.
Now feels out of scope for this book