Summary
While setting up the persistent cache I hit a contradiction between ?set_cache and the implementation: the documentation tells users to set EPIDATR_CACHE_DIRECTORY in .Renviron, but the code reads EPIDATR_CACHE_DIR; the same man page's example calls set_cache(dir = "...") although the argument is cache_dir; and the README's (non-rendered) comment refers to a USE_EPIDATR_CACHE variable that matches nothing in the codebase. Users following the documented workflow silently cache to the wrong location, and copying the documented example errors out. I believe the fixes are one-word renames in three places.
Evidence (dev tip 87b10e1; the EPIDATR_CACHE_DIRECTORY prose and EPIDATR_CACHE_DIR code are the same on main)
- Prose vs. code —
R/cache.R:17-20 (docs):
environmental variables `EPIDATR_USE_CACHE=TRUE` and
`EPIDATR_CACHE_DIRECTORY="/your/directory/here"`in your `.Renviron`, ...
vs. R/cache.R:114-118 (code):
cache_dir <- Sys.getenv(
"EPIDATR_CACHE_DIR",
unset = rappdirs::user_cache_dir("R", version = "epidatr")
)
The parameter table itself correctly says the env var is EPIDATR_CACHE_DIR (R/cache.R:81-84), so the man page contradicts itself.
- Example vs. signature —
R/cache.R:29-30 (docs): "you would call set_cache(dir = "~/my/temporary/savedirectory")" vs. the actual signature R/cache.R:106-113 (set_cache(cache_dir, days, max_size, logfile, confirm, startup)).
- README comment —
README.Rmd:49: "if you have USE_EPIDATR_CACHE=TRUE in your .Renviron" — the code reads EPIDATR_USE_CACHE (R/epidatr-package.R:11-14).
Maintainer-runnable repro
Sys.setenv(EPIDATR_CACHE_DIRECTORY = "/tmp/mydir")
set_cache(confirm = FALSE)
cache_info()$dir
# -> the default rappdirs location; /tmp/mydir was silently ignored
set_cache(dir = tempdir())
# Error in set_cache(dir = tempdir()) : unused argument (dir = tempdir())
Expected vs. actual
- Expected: following
?set_cache's documented workflow configures the cache location; the example runs.
- Actual: the documented env var is ignored (silent), and the documented example call errors.
Suggested fix
- Use
EPIDATR_CACHE_DIR in the prose (or accept both spellings in the code).
- Change the example to
set_cache(cache_dir = "~/my/temporary/savedirectory").
- Correct the README comment to
EPIDATR_USE_CACHE.
I checked for prior reports (open issues #193 "Opt-out-able cache notifications" and #198 "Add table of environmental cache variables" are adjacent; neither covers the wrong names) and found no existing report.
Summary
While setting up the persistent cache I hit a contradiction between
?set_cacheand the implementation: the documentation tells users to setEPIDATR_CACHE_DIRECTORYin.Renviron, but the code readsEPIDATR_CACHE_DIR; the same man page's example callsset_cache(dir = "...")although the argument iscache_dir; and the README's (non-rendered) comment refers to aUSE_EPIDATR_CACHEvariable that matches nothing in the codebase. Users following the documented workflow silently cache to the wrong location, and copying the documented example errors out. I believe the fixes are one-word renames in three places.Evidence (dev tip 87b10e1; the
EPIDATR_CACHE_DIRECTORYprose andEPIDATR_CACHE_DIRcode are the same onmain)R/cache.R:17-20(docs):R/cache.R:114-118(code):EPIDATR_CACHE_DIR(R/cache.R:81-84), so the man page contradicts itself.R/cache.R:29-30(docs): "you would callset_cache(dir = "~/my/temporary/savedirectory")" vs. the actual signatureR/cache.R:106-113(set_cache(cache_dir, days, max_size, logfile, confirm, startup)).README.Rmd:49: "if you haveUSE_EPIDATR_CACHE=TRUEin your .Renviron" — the code readsEPIDATR_USE_CACHE(R/epidatr-package.R:11-14).Maintainer-runnable repro
Expected vs. actual
?set_cache's documented workflow configures the cache location; the example runs.Suggested fix
EPIDATR_CACHE_DIRin the prose (or accept both spellings in the code).set_cache(cache_dir = "~/my/temporary/savedirectory").EPIDATR_USE_CACHE.I checked for prior reports (open issues #193 "Opt-out-able cache notifications" and #198 "Add table of environmental cache variables" are adjacent; neither covers the wrong names) and found no existing report.