[R-pkg-devel] Bioconductor reverse dependency checks for a CRAN package

[Diego Hernangómez Herrero]

Haven’t tried with a package with such an amount of revdeps, but my
approach is revdepcheck in GH actions and commiting the result to the repo
(that is somehow similar to the docker approach if you host the package in
GitHub).

You can check the setup in tidyterra:

- folder with basic setup:
https://github.com/dieghernan/tidyterra/tree/main/revdep
- action (triggered manually):
https://github.com/dieghernan/tidyterra/blob/main/.github/workflows/revdepcheck.yaml

You would need to add revdepcheck folder to .Rbuildignore to avoid notes on
R CMD CHECK and grant write access to GitHub actions on the repo setup so
the results can be pushed to the repo.







Have a nice day!


El El mar, 30 ene 2024 a las 18:39, Ben Bolker <bbolker using gmail.com> escribió:

> https://github.com/r-lib/revdepcheck does the 'step 3 twice' part.
>
>
>    I have had a few issues with it
> <https://github.com/r-lib/revdepcheck/issues/330> but overall it's been
> very helpful.
>
> https://github.com/HenrikBengtsson/revdepcheck.extras may also be useful.
>
> On 2024-01-30 10:56 a.m., Ivan Krylov via R-package-devel wrote:
> > Hello R-package-devel,
> >
> > What would you recommend in order to run reverse dependency checks for
> > a package with 182 direct strong dependencies from CRAN and 66 from
> > Bioconductor (plus 3 more from annotations and experiments)?
> >
> > Without extra environment variables, R CMD check requires the Suggested
> > packages to be available, which means installing...
> >
> > revdepdep <- package_dependencies(revdep, which = 'most')
> > revdeprest <- package_dependencies(
> >   unique(unlist(revdepdep)),
> >   which = 'strong', recursive = TRUE
> > )
> > length(setdiff(
> >   unlist(c(revdepdep, revdeprest)),
> >   unlist(standard_package_names())
> > ))
> >
> > ...up to 1316 packages. 7 of these suggested packages aren't on CRAN or
> > Bioconductor (because they've been archived or have always lived on
> > GitHub), but even if I filter those out, it's not easy. Some of the
> > Bioconductor dependencies are large; I now have multiple gigabytes of
> > genome fragments and mass spectra, but also a 500-megabyte arrow.so in
> > my library. As long as a data package declares a dependency on your
> > package, it still has to be installed and checked, right?
> >
> > Manually installing the SystemRequirements is no fun at all, so I've
> > tried the rocker/r2u container. It got me most of the way there, but
> > there were a few remaining packages with newer versions on CRAN. For
> > these, I had to install the system packages manually in order to build
> > them from source.
> >
> > Someone told me to try the rocker/r-base container together with pak.
> > It was more proactive at telling me about dependency conflicts and
> > would have got me most of the way there too, except it somehow got me a
> > 'stringi' binary without the corresponding libicu*.so*, which stopped
> > the installation process. Again, nothing that a bit of manual work
> > wouldn't fix, but I don't feel comfortable setting this up on a CI
> > system. (Not on every commit, of course - that would be extremely
> > wasteful - but it would be nice if it was possible to run these checks
> > before release on a different computer and spot more problems this way.)
> >
> > I can't help but notice that neither install.packages() nor pak() is
> > the recommended way to install Bioconductor packages. Could that
> > introduce additional problems with checking the reverse dependencies?
> >
> > Then there's the check_packages_in_dir() function itself. Its behaviour
> > about the reverse dependencies is not very helpful: they are removed
> > altogether or at least moved away. Something may be wrong with my CRAN
> > mirror, because some of the downloaded reverse dependencies come out
> > with a size of zero and subsequently fail the check very quickly.
> >
> > I am thinking of keeping a separate persistent library with all the
> > 1316 dependencies required to check the reverse dependencies and a
> > persistent directory with the reverse dependencies themselves. Instead
> > of using the reverse=... argument, I'm thinking of using the following
> > scheme:
> >
> > 1. Use package_dependencies() to determine the list of packages to test.
> > 2. Use download.packages() to download the latest version of everything
> > if it doesn't already exist. Retry if got zero-sized or otherwise
> > damaged tarballs. Remove old versions of packages if a newer version
> > exists.
> > 3. Run check_packages_in_dir() on the whole directory with the
> > downloaded reverse dependencies.
> >
> > For this to work, I need a way to run step (3) twice, ensuring that one
> > of the runs is performed with the CRAN version of the package in the
> > library and the other one is performed with the to-be-released version
> > of the package in the library. Has anyone already come up with an
> > automated way to do that?
> >
> > No wonder nobody wants to maintain the XML package.
> >
>
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

	[[alternative HTML version deleted]]