Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gdalcubes::st_as_stars does not find R-packages #80

Open
hewag1975 opened this issue Mar 2, 2023 · 1 comment
Open

gdalcubes::st_as_stars does not find R-packages #80

hewag1975 opened this issue Mar 2, 2023 · 1 comment

Comments

@hewag1975
Copy link

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 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.

Dockerfile.zip

Any idea on this? Let us know if you need more information.
Best,
Hendrik

@appelmar
Copy link
Owner

appelmar commented Apr 12, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants