Hi All Shiny community!
I just started a new job where they use shiny.
"So, pardon me for any silly question I raise"
The organization have created multiple shiny apps under the same Shiny folder: Shiny/app1 Shiny/app2 Shiny/app3
All the different apps (app1, app2...) read from the same R library path.
Meaning the old apps using old package versions will have clashes
if I want to use new libraries to develop app12.
I am looking to restructure the architecture so that each app has its own R library path.
So that even apps build in 1922 will still function because they will have its own libraries environment.
What would be the best practice when maintaining old and new apps under the same roof?
Note* other useful info - they are all served using shiny-server on CentOS. http://virtualmachinename/shiny/app1 http://virtualmachinename/shiny/app2...
My idea is use renv package to encapsulate R version and dependencies particular to each app.
I read that shiny creates one single R session per app and it uses this for all Apps.
Correct me If I am wrong with the following statement:
renv and shiny will not work on its own and you need to use docker in order to encapsulate each of the apps.
Questions:
Can shiny and renv sove my issue without docker? or not?
Are other alternatives such as variables on shiny configuration files that I am not aware and this problem can be solved in a more easy/straight forward way?
If the implementation is renv and docker would it have any effect on shiny app responsiveness/loading speed? or other collateral issues?
Don't blame me if there are answers out there about how to solve this.
I found lots of good resources but I couldn't figure out how to connect all the pieces together.
what approach should I take and why is the best approach for this specific problem.
yes, renv would solve your problem without docker.
In our company, we started to use checkpoint in connection with Microsoft R Open long before renvwas available because we did not like packrat (sorry...). The MRAN provides a daily snapshot of CRAN. So, instead of fixing each package version (which only renv managed to provide recently) we fixed all packages by a snapshot date to ensure reproducibility (package checkpoint).
By the way, renv internally uses the CRAN snapshots to download older package versions. It has an internal lookup table for that.
my only left question then is:
since all the old apps DO read from the default R path and the new developed app uses renv.
"I attempted to use the old and new app on a session and does not work"
Therefore, the way to proceed is by:
install renv and all libraries for each of the old apps
change some shiny-server configurations so that when a user click on an app the R path is the one found in the app itself.
Is step 1 and 2 true?
If so,
I know how to proceed with point 1, but not for point 2.
Do you know what needs change on the configuration side if any?
Point 1 is correct, point 2 is not necessary because renv will take care of it when set up properly.
In an R session/instance packages are loaded from the library paths which can be displayed by .libPaths(). You will get different library paths for each project by using renv.
The key idea is to have a different set of packages associated to each project.
Play around with renv in several dummy projects to understand how it works. Then try to apply it to an existing projects. It might require some fiddling with package versions if things don't.
@nirgrahamuk, This is very interesting, could you give a simple description of your setup and workflow? For example, Do you develop the apps on a computer and deploy to another? If so, How do you get renv synced with the deployment server?
I don't expect a detailed explanation (although, a blog post about this would be great), that would be too much to ask, I just want an overview.
typically they are developed on my Win10 laptop and published via the standard rsconnect to shinyapps.io
I think rsconnect still wont directly use renv ( though it should in the future)
so theres more of a happy accident, that the renv.lock notes for me the libraries myself and colleages would need locally to reproduce the project, and rsconnect does its old fashioned work of detecting dependencies. its just that those dependencies should have been dictated by what version of a package I had used renv to install in for the project i.e. did I do install("dplyr@0.8.2") or install("dplyr@1.0.2’") etc.
I see, I was hoping you were deploying to your own server. I'm interested on implementing this but I haven't had the time to experiment my self on a test server before implementing it in production "ish", so it would have been nice to learn from a similar experience.
Hi guys a quick update I got renv and shiny-server working!
Thanks again for all input shared.
@andresrcs I am indeed using a server within a company network to server shiny dashboards across teams.
I don't know much it but can tell you what I know and other people can fill the gaps.
In order to isolate the R libraries to a particular shiny-app you need to:
create 1 R project for each shiny app.
create for each R project the renv.
renv creates .Rprofile file which ones you open an R project it sets the R path.
I believe when users access the shinny apps they are accessing directly to the application hosted in the server. That application which is an R project with its own renv gets activated. All dependencies and libraries are self-contained. *Note I develop apps in the server.
