-
Notifications
You must be signed in to change notification settings - Fork 370
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
Trying out an easy fix for setting the custom tmp folder. #1908
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kockan This seems sane to me. I might put a comment mentioning the timing issue in it.
@kockan Have you tested that this fixes the issue? Can you reproduce it/ |
@lbergelson Yes, it does. Here's a run with the main branch:
vs. a run with the feature branch:
|
@lbergelson I am also worried about the "instantiating the intel libraries" part, though this comes before any of that really happens, so unless those require the default system tmp dir, it should be fine, but happy to look at alternatives if it actually might break those. |
@kockan I had misread it when I posted (and deleted) that comment. I think it should be good. It happens before those still. |
Picard command-line programs that check for R installation do so in the customCommandLineValidation() method under parseArgs(). If the user wants to set a custom tmp directory via the
--TMP_DIR
flag, this will not go into effect since any usages of--TMP_DIR
happen after parseArgs(). Therefore RExecutor will try to copy the R script that checks whether R is installed to the default system tmp folder and attempt to run the script from that location.This is an attempt at fixing this timing issue by moving the work related to
--TMP_DIR
inside parseArgs(), before customCommandLineValidation() is ever called. I'm not sure whether this is the best long-term solution, but it seems to fix the issue.Related issue: #1907