Improve user interface for subsetting of package checks

[ddsjoberg]

Hello! I haven't played around with this tool yet, so apologies if this is already possible.

I am thinking ahead to when gtsummary is more integrated with other packages we maintain. The package currently has 21 reverse dependencies on CRAN and I foresee myself checking our internal rev deps more often/regularly than the community rev deps. With that in mind, it would be great to have an option to only check specified rev deps.

Thanks! Looking forward using this!!

[dgkf-roche]

The tools for this are exported, but certainly still maturing. Don't be surprised if the function names/args evolve a bit as we start to explore what types of features people are looking for.

The surface level API allows specifying a package using a source path, but if we go one level deeper we can first plan out which tasks we want to run and then filter those however we want before actually running them:

checks <- rev_dep_check_tasks_df("../praise")
#>                               alias version                      package                  custom
#> goodpractice     goodpractice (dev)   1.0.5    <task goodpractice (dev)>     <task praise (dev)>
#> goodpractice1 goodpractice (v1.0.0)   1.0.5 <task goodpractice (v1.0.0)> <task praise (release)>
#> testthat             testthat (dev) 3.2.1.1        <task testthat (dev)>     <task praise (dev)>
#> testthat1         testthat (v1.0.0) 3.2.1.1     <task testthat (v1.0.0)> <task praise (release)>

# admittedly, this is a bit clunkier than I'd like, expect this to get cleaner
checks <- checks[grepl("testthat", rownames(checks)),]

# runs the filtered set of `R CMD check`s
run(new_check_design(checks))

Thanks for raising the use case. I'm going to convert the issue to an enhancement request for a few usability enhancements I'm seeing:

---

Proposed Changes

To try to make this a bit less clunky, I'm seeing a few things that could make this easier to work with:

• [ ] Subsetting the checks data.frame drops the class on the package column, so the print method goes all wonky after subsetting. Probably most easily handled by using vctrs/pillar, but we'll need to weigh the new dependencies.
• [ ] The rownames are made unique with these trailing 1s which makes it much hard to subset for specific packages
• [ ] The task type should be indicated in the formatted string (not clear from this output, but $package is a specification for a "reverse dependency task" and $custom is the specification for a "install task") Maybe we should restructure it as a single $tasks column that contains a list of necessary tasks for each row in the data.frame.
• [ ] We can probably add a default run.data.frame method that automatically runs new_check_design

With these changes, you might expect something like this:

[!WARNING]
Non-functional Proposed API

checks <- rev_dep_check_tasks_df("../praise")
#>                 alias      package version                                                       tasks
#>    goodpractice (dev) goodpractice   1.0.5        [<install praise (dev)>, <check goodpractice (dev)>]
#> goodpractice (v1.0.0) goodpractice   1.0.5 [<install praise (release)>, <check goodpractice (v1.0.0)>]
#>        testthat (dev)     testthat 3.2.1.1        [<installtask praise (dev)>, <check testthat (dev)>]
#>     testthat (v1.0.0)     testthat 3.2.1.1     [<install praise (release)>, <check testthat (v1.0.0)>]

checks <- checks[checks$package %in% c("testthat"),]

run(checks)