Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hoardr cache issue on MacOS #411

Open
djhocking opened this issue May 23, 2022 · 2 comments
Open

hoardr cache issue on MacOS #411

djhocking opened this issue May 23, 2022 · 2 comments
Assignees

Comments

@djhocking
Copy link
Collaborator

Checking cubble creates ~/Library/Caches/R/noaa_ghcnd/ on macOS, not an
allowed area under the CRAN policy.

Likely this comes from rnoaa which has

hh <- hoardr::hoard()
hh$cache_path_set("noaa_ghcnd")
ghcnd_cache <<- hh

where

rnoaa:::ghcnd_cache

path: noaa_ghcnd cache path: ~/Library/Caches/R/noaa_ghcnd

although rnoaa does not itself use the area it seems to use hoardr for
other similar purposes.

rnoaa needs an urgent update to correct these potential policy
violations: before 2022-05-25 or it, cubble and its other revdeps Z10
and wildviz will have to be removed from CRAN.

Further, neither cubble nor rnoaa are cleaning up after use:

% ls -l ~/.cache/R/noaa_ghcnd/
total 12156
-rw-r--r-- 1 ripley bdr 2019110 May 14 20:55 ASN00066037.dly
-rw-r--r-- 1 ripley bdr 326035 May 14 20:55 ASN00066059.dly
-rw-r--r-- 1 ripley bdr 2944659 May 14 20:55 ASN00066062.dly
-rw-r--r-- 1 ripley bdr 1034884 May 14 20:55 ASN00066124.dly
-rw-r--r-- 1 ripley bdr 483139 May 14 20:55 ASN00066194.dly
-rw-r--r-- 1 ripley bdr 1053429 May 14 20:55 ASN00086038.dly
-rw-r--r-- 1 ripley bdr 409317 May 14 20:55 ASN00086068.dly
-rw-r--r-- 1 ripley bdr 1060235 May 14 20:56 ASN00086077.dly
-rw-r--r-- 1 ripley bdr 1201999 May 14 20:56 ASN00086282.dly
-rw-r--r-- 1 ripley bdr 1903365 May 14 20:55 ASN00087031.dly

as required by the policy.

As the CRAN policy says

"The time of the volunteers is CRAN’s most precious resource,"

and this wasted a couple of hours of time much needed for the many
thousands of responsible CRAN maintainers.

@djhocking
Copy link
Collaborator Author

@sckott - For now, I think I can fix the above CRAN issue by using the full_path option in hoardr and then putting full_path = tools::R_user_dir("rnoaa/noaa_cpc", which = "cache") in it to ensure that it meets the cache location requirements for R 4.0. When I use the full path option the "path:" display from hoard is blank even if I specify path = in the cache_path_set() function because it's not within that part of the if-else function. I'm not sure if it matters. I'm new to R6, hoardr, and caching rules.

Mostly I'm letting you know here to see if you want to address it at all within the hoardr package itself.

@sckott
Copy link
Contributor

sckott commented May 24, 2022

Sorry about that, ugh. Thanks for letting me know. I probably won't have time to fix in hoardr.

It would probably make your life easier not to do any caching in rnoaa and leave it to the user. Could rip out all the caching code, and not deal with all the cran complaints. But up to you of course.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants