-
Notifications
You must be signed in to change notification settings - Fork 33
Description
This is based on my recent experience doing revdepchecks for vroom. As of 2026-01-23, vroom has impactr as a revdep:
https://cran.r-project.org/web/packages/impactr/index.html
And here's its DESCRIPTION right now:
Package: impactr
Title: Mechanical Loading Prediction Through Accelerometer Data
Version: 0.4.1
Authors@R:
person(given = "Lucas",
family = "Veras",
role = c("aut", "cre"),
email = "[email protected]",
comment = c(ORCID = "0000-0003-0562-5803"))
Description: Functions to read, process and analyse accelerometer
data related to mechanical loading variables. This package is
developed and tested for use with raw accelerometer data from
triaxial 'ActiGraph' <https://actigraphcorp.com> accelerometers.
License: MIT + file LICENSE
URL: https://lveras.com/impactr/
BugReports: https://github.com/verasls/impactr/issues/
Encoding: UTF-8
LazyData: true
Roxygen: list(markdown = TRUE)
RoxygenNote: 7.2.1
Imports:
glue,
lubridate,
lvmisc,
pillar,
pracma,
purrr,
Rcpp,
rlang (>= 0.4.6),
signal,
stringr,
tibble,
toOrdinal,
utils,
vroom
Suggests:
accdata,
covr,
knitr,
rmarkdown,
testthat (>= 3.0.0)
Config/testthat/edition: 3
LinkingTo:
Rcpp
VignetteBuilder: knitr
Language: en-GB
Depends:
R (>= 2.10)
Additional_repositories: https://lveras.com/drat/
It Suggests accdata, which is supposed to be available from the Additional_repositories: https://lveras.com/drat/. But that repository does not currently exist.
~/work/vroom % curl -I https://lveras.com/drat/src/contrib/PACKAGES
HTTP/2 403
alt-svc: h3=":8443"; ma=2592000
server: Caddy
date: Sat, 24 Jan 2026 01:46:19 GMT
~/work/vroom % curl -I https://cloud.r-project.org/src/contrib/PACKAGES
HTTP/2 200
content-length: 5711710
date: Sat, 24 Jan 2026 01:46:59 GMT
expires: Sat, 24 Jan 2026 02:16:59 GMT
server: Apache/2.4.65 (Unix)
last-modified: Sat, 24 Jan 2026 00:31:16 GMT
etag: "57275e-6491764598047"
accept-ranges: bytes
cache-control: max-age=1800
x-cache: Miss from cloudfront
via: 1.1 36d4ca7ddc4beff9d1b963574f5a4134.cloudfront.net (CloudFront)
x-amz-cf-pop: YVR52-P3
x-amz-cf-id: 8Orpg5Pk3i4uJsa-iNH_gNdShgzquldFfQSZbpthkDiiuY13pgmJtA==
Here's how it looks when I try to install local dev deps with pak:
> pak::local_install_dev_deps()
✔ Loading metadata database ... done
Run `[rlang::last_trace()](vscode-file://vscode-app/Applications/Positron.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html#)` to see where the error occurred.
Error:
! ! error in pak subprocess
Caused by error:
! Could not solve package dependencies:
* deps::/Users/jenny/tmp/impactr: Can't install dependency accdata
* accdata: Can't find package called accdata.In cloud revdep checks, this particular package seems to just hang, causing the entire job to be stuck at 1 thing still in progress and n - 1 things being complete. Eventually, somewhere north of 2 hours, something appears to time out and you can run cloud_report(), which does not report anything about this problematic package.
I have a couple of wishes:
- Can this doomed situation fail fast and be logged in the problems? Feels like it fits in the "failed to check" bucket.
- Can we make it easier to find out which revdeps are still running? Part of what makes this situation tricky is that I can't see which package is the zombie. If I could, that unblocks me to do some local, artisanal troubleshooting. In this case, I have to wait 'til it's the only check still running, do
cloud_report(), back out which packages have been checked, get the list of revdeps viarevdepcheck::cran_revdeps("vroom"), then usesetdiff()to figure out who's missing. - Given that this situation only generates a NOTE in CRAN's checks, should we be doing something different? Here's what CRAN shows for impactr at this moment:
