When my shiny app boots up, shiny is loaded by default from .libPaths()[2] , which then imports R6V.2.2.1 , also from this path.
However, my code depends on R6>= V.2.2.2 , which I have in .libPaths()[1].
It would be simple enough to have my SysAdmin update R6 in .libPaths()[2] , but they cannot because other people's apps depend on the libraries on that path, and we don't want to break those.
I would check out withr::with_libpaths and see if that can solve your issue.
I believe the core issue is coming from shiny depending on R6. I would install shiny directly into your first libpath and then only use that libpath when running your shiny app. You then have full control over which library versions are in that folder at execution time. (No need to depend on university maintained folder.)
As you've found out, you are stuck once the package is loaded. R doesn't behave well when unloading a pkg that another pkg uses directly.
I'm also guessing that you can't use callr::r to do calculations. This would launch a new process and you'd get control over which pkgs are loaded. But would only work as a on off calculator, not an interactive R session.
You said the Shiny Server is run by the university. I'm wondering if you can ask the admin to add this line to the config: (replace shiny with whichever user they are currently using)
This should run the apps in your folder under your user name, which should then load your ~/.Rprofile, which would allow you to set the appropriate .libPaths().
It is worth an ask to your admin. You're not asking for sudo privileges, just your existing user privileges.
If they already do this, make sure you have a ~/.Rprofile that adds your correct .libPath().
Thanks Barret! I'll ask my SysAdmin and report back. You are a saint. =)
One quick consideration: The app's files (global, server, ui, etc...) is actually stored in /srv/shiny-server/name_of_app. Does that change the 3 lines of code in the config?
A location configured to use user_dirs will allow users on the system to create and manage their own Shiny applications and make them available in their home directories. This directive will host any application stored in an eligible user's ~/ShinyApps directory publicly at a URL prefaced by their username.
This privilege can be restricted only to users of particular groups using the members_of restriction. For instance, the following configuration:
run_as :HOME_USER:;
# Define the root location
location / {
user_dirs;
# Only allow members of the 'shinyUsers' group to host personal applications.
members_of shinyUsers;
}
will, for any user who is a member of the shinyUsers group, publicly host any Shiny application available in the user's ~/ShinyApps directory. For instance, if a user named tina who is a member of the shinyUsers group, has /home/tina as a home directory, and has an application called shinyApp1 in /home/tina/ShinyApps/ , that application would be available on this server at the URL http://server.com/tina/shinyApp1 . Any other application in /home/tina/ShinyApps/ would also be publically available at a similar URL.
My understanding of this is that if they add rpauloo to the shinyUsers group on the university server, you could host an app that is located in your personal home directory, /zeolite/rpauloo/shinyApps/RichShinyApp/{app,ui,server}.R. This would mean permissions wouldn't need to be altered for any existing apps currently in place (brownie points for the admin) and it would give you full control over your personal app and your .Rprofile. Your app should then be reachable at http://server.com/rpauloo/RichShinyApp once deployed.
I actually think it's simpler than all that; you should be able to put an .Rprofile file directly in your app directory, and it will be respected, no matter what user launches it. No need to modify the Shiny Server config or anything. This is in fact how packrat works.
Hi @jcheng, thanks for taking an interest in this question. I tried putting both .Rprofile and Rprofile.site files in my home directory and the app directory (along with the global, server, ui files) that set the .libPaths() like so:
.First <- function(){ .libPaths(.libPaths()[1]) }
These don't fix the underlying error. R6 is still loaded from .libPaths()[2], and throws: ... namespace 'R6' 2.2.1 is already loaded, but >= 2.2.2 is required...
I'm working with my SysAdmin on this now, and will report a working solution when we find one.
Any advice in the interim is very much appreciated. Thanks for your consideration.
If your question's been answered (even by you!), would you mind choosing a solution? It helps other people see which questions still need help, or find solutions if they have similar problems. Here’s how to do it: