cronR retains Job identifier and Rscript repository path from last user

[richardrawstronMOH]

In RStudio Server the the cronR Addin can be used to schedule a task. When scheduling a task it appears the following values are retained from previous scheduling actions.

• Job identifier
• Rscript repository path This is problematic with multi-user systems i.e. other users values are presented. I would not expect these fields to be populated by a value another user has entered when I execute the cronR Addin.

Steps to Reproduce:

1. Open RStudio Server
2. Click Tools > Addins > Browse Addins…
3. Select cronR > Execute
4. Schedule cronR task
5. Open RStudio Server as different user
6. Click Tools > Addins > Browse Addins…
7. Select cronR > Execute Fields populated with values entered by first user

This was raised with RStudio support who advised the issue is with the cronR package. _When we run this for the first time in a new session in a local RStudio Server Pro environment, we see the following output: The image shows that the function starts a shiny app for the cronR UI, and does not use the RStudio Server Pro IDE UI.

One thing to note is that value in the launch, and log location seems to be stored somewhere. From the following screenshot, you can see the path loaded after starting a completely new session:

The value above is one we updated in an old session. Somewhere the cronR package is storing this information. And we believe the package maintainers will have a better idea as to where the value is cached._

Environment RStudio Server Pro Version 1.4.1106-5 Red Hat Enterprise Linux 8 cronR 0.4.2

[jwijffels]

The cronR package does not store the job identifier.

• The default job identifier is sprintf("job_%s", digest::digest(runif(1))) as https://github.com/bnosac/cronR/blob/master/R/cron_rstudioaddin.R#L76 which is every time different unless your R startup code sets the seed somewhere

The package does store the 'Rscript repository path' at file.path(system.file("extdata", package="cronR"), ".RscriptRepository.rds") as you can see in the code at `https://github.com/bnosac/cronR/blob/master/R/cron_rstudioaddin.R#L25 in order not to have to type that path in there every time.

If you have multiple users, just let them install the cronR package again (in their own user folders) instead of having a system-wide cronR package. That will solve your remark as the package will then be loaded from their own folders as it will load cronR from the first location where it finds it in .libPaths()

[richardrawstronMOH]

Thanks for looking at this.

Apologies for incorrectly including the default job identifier. You are correct this is a unique value every time the cronR Addin is opened. It is only the Rscript repository path that is retained.

Unfortunately the solution you propose (allow each user to install their own cronR package) will not work in our environment.

Environment setup

• RStudio Server on RHEL8
• 3 versions of R installed
• Each R version has separate System and User libraries e.g. System == .libcurrent <- '/opt/rprod_lib/R/r_sitelib_3.6.3_20201131' User == .libcomm_current <- '/opt/rprod_lib/R/community/r_commlib_3.6.3_20201131'
• System and User libraries are common/shared by all users i.e. users do not have their own System and User libraries (in separate folders)
• Libpaths is configured to use System library over User library
• System library is managed by administrators i.e. users can not write to this library.
• User library is managed by users i.e. users can write to this library.
• cronR is installed into System library (by admins)

The environment was setup in this manner to provide a more consistent managed environment for the R community in my organisation.

So the short of this is that:

1. Installing per user copies of cronR is not feasible.
2. cronR still functions by writing to the Community library
3. when a user schedules using cronR they will see the Rscript repository path entered by the previous use (which is less than ideal).

Would you consider changing the cronR package to use the Sys.getenv("HOME") value for the Rscript repository path location? Or making this a configurable option? This would result in a per user entry.

On a related note a workmate is looking through the code with a view to provide a suggestion for you. Thanks

[jwijffels]

If you have a proposal of code changes, feel free to provide these here or as a pull request. I'm open towards any changes regarding this, either by changing the path of .RscriptRepository.rds or the default of the Rscript repository path: launch & log location in the user interface.

Note however that CRAN policy is as follows (https://cran.r-project.org/web/packages/policies.html)

Packages should not write in the user’s home filespace (including clipboards), nor anywhere else on the file system apart from the R session’s temporary directory (or during installation in the location pointed to by TMPDIR: and such usage should be cleaned up). Installing into the system’s R installation (e.g., scripts to its bin directory) is not allowed.

Current implementation also writes in the package extdata folder so this went unnoticed probably due to this code https://github.com/bnosac/cronR/blob/master/R/cron_rstudioaddin.R#L26

Either way, feel free to provide solutions.

[richardrawstronMOH]

Thanks for being open to changes and for pointing out the CRAN policy. I was unaware of that but it clarifies why cronR behaves as it does. With that in mind it's less immediately clear what a good solution would be.

I'll lean on my workmate and see what we can do.

[jwijffels]

I see the following 2 options:

1. make sure your end users don't have write access to the location where you installed cronR system-wide. Then because of https://github.com/bnosac/cronR/blob/master/R/cron_rstudioaddin.R#L26, the Rscript repo will always be in a tempfolder and will be persistent across the R session but not when the user restarts R
2. change the R code at https://github.com/bnosac/cronR/blob/master/R/cron_rstudioaddin.R#L12 to use some sort of agreed folder which the user can change in .Renviron itself if needed. Something likecron_rstudioaddin <- function(RscriptRepository = Sys.getenv("CRON_LIVE", unset = getwd())) {

[s7clarke10]

Hi,

I work with Richard who has raised the request above.

I tried call the cronR add-in from the command line like so which defaulted to my current working directory.

cronR::cron_rstudioaddin(getwd())

So if proposed option 2 works similar to that above to default to the current working directory this would be perfect for us. If we have any users who wish to default their location, they could always set the by CRON_LIVE environment variable else it will default to the current working directory. If this is how the proposed change will work it will be great.

Thanks Steve

[jwijffels]

If you can prepare a request, I'll review it.

[hedsnz]

This PR removes the reliance on extdata completely -- I wasn't sure if that's what you were suggesting. Thanks for your time to review it. #40