You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
we are using gdalcubes inside a shiny app hosted on a shiny server. To simplify server maintenance, R-packages are not installed in a user library, but in a global (shared) library and .libPaths() is adjusted accordingly and globally through .Rprofile.site. The whole setup used to work fine for quite some time. A few weeks ago we noticed that the shiny app breaks when calling gdalcubes::st_as_stars() stating that it cannot find the package jsonlite (which is installed in the shared library in the latest version). Our assumption was that this is caused by the parallelization process not accessing the R-packages in the shared library. To test this hypothesis we installed all required packages a second time into a user library for the shiny user and everything works again. Even though this might be related to our specific server setup, we think that installing R-packages to a different location should not break the code.
To make this somehow reproducible for you, we have created a Docker image with a reprex. The attached Dockerfile uses our image and first runs the reprex in a default situation where the R-packages are installed to the default R-library inside the Docker (/usr/local/lib/R/site-library/). The reprex completes as expected. Then the library is moved to a different library location (simulating the shared location, /opt/R/shared/4.2), .libPaths() is adjusted via .Rprofile and the reprex is re-executed and fails.
We logged the build process using docker build --no-cache --progress=plain . -t issue:0.0.1 -f Dockerfile &> issue.log
Note that you need to monitor the log file as the build process is suspended.
Thanks and sorry for looking at this so late. I think the example should work now (thanks for the reprex + Dockerfile) with the latest commit (see above).
For completeness: currently the fix only works if .libPath() is set in the user or site-wide .Rprofile or Rprofile.site files respectively. Changing .libPath() in scripts will still produce errors.
Hi Marius,
we are using
gdalcubes
inside a shiny app hosted on a shiny server. To simplify server maintenance, R-packages are not installed in a user library, but in a global (shared) library and.libPaths()
is adjusted accordingly and globally through.Rprofile.site
. The whole setup used to work fine for quite some time. A few weeks ago we noticed that the shiny app breaks when callinggdalcubes::st_as_stars()
stating that it cannot find the packagejsonlite
(which is installed in the shared library in the latest version). Our assumption was that this is caused by the parallelization process not accessing the R-packages in the shared library. To test this hypothesis we installed all required packages a second time into a user library for the shiny user and everything works again. Even though this might be related to our specific server setup, we think that installing R-packages to a different location should not break the code.To make this somehow reproducible for you, we have created a Docker image with a reprex. The attached Dockerfile uses our image and first runs the reprex in a default situation where the R-packages are installed to the default R-library inside the Docker (
/usr/local/lib/R/site-library/
). The reprex completes as expected. Then the library is moved to a different library location (simulating the shared location,/opt/R/shared/4.2
),.libPaths()
is adjusted via.Rprofile
and the reprex is re-executed and fails.We logged the build process using
docker build --no-cache --progress=plain . -t issue:0.0.1 -f Dockerfile &> issue.log
Note that you need to monitor the log file as the build process is suspended.
Dockerfile.zip
Any idea on this? Let us know if you need more information.
Best,
Hendrik
The text was updated successfully, but these errors were encountered: