Using unallowed path?

[steffilazerte]

Happy New Year!

In my weathercan package I included an option for saving a data frame of stations data to a cache directory, found with rappdirs.

stations_file <- function() {
  file.path(rappdirs::user_data_dir("weathercan"), "stations.rds")
}

However, I recently heard from CRAN

"And if I run stations_dl() it asks

weathercan would like to store the updated stations data to:
~/Library/Application Support/weathercan/stations.rds

which is not an allowed area under the CRAN policy"

I definitely don't blame you for my package getting booted, but I thought I might check in case I used the function incorrectly, or there was a change to CRAN policy. Any suggestions?

[gaborcsardi]

You can use tools::R_user_dir() instead of rappdirs?

[adamhsparks]

I too received an e-mail from CRAN out of the blue that getCRUCLdata violated policy in this way. I’ve been using rappdirs for several years with it and haven’t made any changes to that package on CRAN in at least a year I think. Has there been a policy change with CRAN somewhere?

I just gave the go ahead to archive the package from CRAN and left it in the rOpenSci R Universe rather than try to sort the issue out.

[gaborcsardi]

@hadley Should we have another function that works similarly to tools::R_user_dir() but people can use it for older versions of R? OTOH people can also use the backports package for this?

[hadley]

CRAN policy seems to be a moving target, and they don't seem at all interested in working with rappdirs, despite it being used by many packages, so yeah, seems like a backport might be a better option.

[cboettig]

Why doesn't rappdirs merely wrap tools::R_user_dir() whenever the R version is new enough for that to be available?

(alternately rappdirs could try to always return tempdir path during testing/examples run on CRAN, but that's probably hard and fragile).

[gaborcsardi]

Why doesn't rappdirs merely wrap tools::R_user_dir() whenever the R version is new enough for that to be available?

You can use rappdirs to query directories for other apps as well, e.g.

❯ dir(rappdirs::user_config_dir("RStudio", NULL))
 [1] "blob_storage"             "Cache"
 [3] "Code Cache"               "config.json"
 [5] "Cookies"                  "Cookies-journal"
 [7] "DawnCache"                "GPUCache"
 [9] "Local Storage"            "Network Persistent State"
[11] "Preferences"              "QtWebEngine"
[13] "Session Storage"          "SingletonCookie"
[15] "SingletonLock"            "SingletonSocket"
[17] "TransportSecurity"

should return the correct place on all platforms.

(alternately rappdirs could try to always return tempdir path during testing/examples run on CRAN, but that's probably hard and fragile).

Yes, that does not really work if you use another package or tool during the tests/checks, that would be also redirected to tempdir, not just the tested package.

[hadley]

@cboettig also what happens if there was important stuff stored in the directory that the older versions of R used? I think it's hard to totally automate this.

[cboettig]

Thanks @hadley @gaborcsardi , that all makes sense.

I have migrated most of my packages to the tools::R_user_dir, or added an env var override to default dirs for use in examples/tests, which has at least kept CRAN happy. (not sure if providing env var overrides by default as in R_user_dir behavior would help? of course CRAN doesn't tell us if they set those to tempdir in their test platform).

Given that rappdirs is widely used (even the docs for tools::R_user_dir() reference it 😂 ), and the realities of 'CRAN policy' I imagine developers coming to rappdirs will continue to run afoul of CRAN. I can understand why you wouldn't want to make claims about what CRAN policy is/isn't okay within the rappdirs docs (given the moving and not always consistent nature there), but at the same time making no mention of this or the alternatives seems like it might lead people to future frustration.

Anyway thanks for your explanations and all you do to support the R community! 🚀

[hadley]

Yeah, I think at some point we'll just supersede this package and point folks to tools::R_user_dir() instead.

[gaborcsardi]

We could probably add some of these arguments to the README.

[hadley]

Yeah, and I think we should probably steer new users away from the package. Maybe include a backported version of R_user_dir() etc in rappdirs for folks who need it in older R versions?

[datapumpernickel]

Just checking in on this. I recently had my package removed from CRAN for a policy violation due to the use of rappdirs. I do not blame you at all for changing policies of CRAN, but I think the hint in the documentation that rappdirs is compliant with CRAN policies is definitely misleading and should be changed soon. Thank you!

[hadley]

The plan is to deprecate rappdirs in the near future.

[gaborcsardi]

@hadley Actually, there are at least three reasons for using rappdirs, still:

1. It is useful to get the places where other software, e.g. RStudio, store their files.

   ❯ file.path(rappdirs::user_config_dir("RStudio"), "config.json")
   [1] "~/Library/Application Support/RStudio/config.json"
   

2. R_user_dir() is (de facto) incorrect on macOS config files:

   ❯ tools::R_user_dir("", "config")
   [1] "/Users/gaborcsardi/Library/Preferences/org.R-project.R/R/"
   

3. Compatibility with the packages that are currently using it.

AFAICT there is nothing wrong with using rappdirs, as long as your tests and examples (and the tests and examples of other packages using your package!) do not create any files.

This said, we can encourage people to use R_user_dir() instead of rappdirs, so I guess we can deprecate it, so people stop using it. Personally I am going to keep using it, at least the versions that are vendored into some packages.

[hadley]

@gaborcsardi ah that makes sense. We can definitely keep it around, but most people will be best served by using the R functions now, I think.