Closed yogat3ch closed 6 months ago
I think I know why this is now.
We're using renv
to restore all of the dependencies for our golem
app. renv
writes all the packages to it's own library directory, rather than the standard R library directory.
I think the R session that launches in the background is likely using the default library path, and isn't inheriting from the parent session.
Does the background R session loaded by mirai
load the local .Rprofile as a typical R session? I could add code to the .Rprofile to solve this if so. I'm going to test that out
Yes, the background R sessions should read .Rprofile
.
You can also manually supply library paths to the library
argument of controller$push()
: https://wlandau.github.io/crew/reference/crew_class_controller.html#method-crew_class_controller-push
Prework
crew
package itself and not a user error, known limitation, or issue from another package thatcrew
depends on. For example, if you get errors runningtar_make_clustermq()
, try isolating the problem in a reproducible example that runsclustermq
and notcrew
. And for miscellaneous troubleshooting, please post to discussions instead of issues.Description
crew
seems to be working fine in all of our AWS environments except for one in which very bizarre behavior is happening. The background tasks launched bycrew
give an error indicating that thecrew
package doesn't exist. Here's the logs written bycrew
that show this anomaly:Reproducible example
I'm unable to do so as it involves running in a remote arm64 linux container on AWS.
Expected result
On all of our other environments,
crew
seems to function. On this environment, on occasion,crew
will cause intermittent errors with these logs. Have you encountered anything like this? How mightcrew
launch a worker, and then launch a task that is unable to find thecrew
package on that worker when trying to run the task? Perhaps it's somehow loading with a different library path? I'm stumped.Diagnostic information
R. 4.3.0 on aarch64-unknown-linux-gnu (64-bit)