Package any script file

[nuest]

• 1. containerit executes the script locally and reproduce the session that results by the end of the script
• 2. copy = script (default) copies the supplied script to the image,
• 3. copy = script_dir also copies the script and all files / directories of the same folder
• 4. copy takes a list of files and directories to be copied to the folder
• 5. cmd parameter can be set with Cmd_Rscript("path/to/script") resulting to
  CMD ["Rscript", "--save", "/path/to/Rscript"]
• 6. Test 1-5 with test scripts

- [ ] 1. Default: execute a script locally and reproduce the session that results by the end of the script
- [ ] 2. copy_script = TRUE also copies the script
- [ ] 3. copy_parent = TRUE also copies the script and all files / directories of the same folder
- [ ] 4. batch_exec = TRUE also copies script and sets CMD instruction to
CMD ["Rscript", "--save", "/path/to/Rscript"]
- [ ] 5. copy_files takes a list of files and directories to be copied to the folder
- [ ] 6. Test 1-5 with test scripts

Issues (to be discussed later)

• How to handle: R working directory, relative/absolute paths, build context

[nuest]

I'm not sure about the parameter names for 2, 3 and 5. We could also have copy parameter that takes a list of files. I would suggest to use one copy parameter with the following options:

• script (the default, copies only the script file passed to the function), same as copy_script
• script_dir (copies all files in the script dir including the script), same as copy_parent
• a list which is treated as a list of file paths, same as copy_files

This way we do not have to handle potential conflicts between these options. And in the end, a user can always manually add copy statements anyway.

We also need a parameter for the copy destination within the container. My suggestion is /payload as a default.

Regarding 4: What about a helper function that creates a command instruction from the filename?
dockerfile(scriptfile = "myscript.R", ... , copy_destination= "/payload", cmd = create_cmd_runscript("myscript.R"))

[I am not sure this even works, my memory might fail me here.]

[MatthiasHinz]

@nuest I updated the checklist

For copy destination I would use either "payload/" or "/payload/".

I did the first thing for now, so that the file lands in the R working directory instead of the file system root. Docker requires a 'folder' to end with a trailing slash, otherwise the data will be written to a file named "payload" and filenames are not preserved.

[MatthiasHinz]

From my experience, I think that the restriction working directory = build context suggests itself at for the early stages of development. This is because

• Dockerfiles refer to resources (e.g. via copy/add) with paths relative to the build context
• R scripts may refer to other files with paths relative to the working directory
• R users often supply file paths relative to the R working directory
• For sessionInfo reproduction, we execute R-scripts locally and create the Dockerfile both in one step.

[MatthiasHinz]

The following R commands now reproduce the Dockerfile below. All files and folders that are in the same directory as the R script are copied to the image. The directory structure of the workspace is reproduced in the directory 'payload' (default workdir). The cmd parameter makes the same script execute when running the container with default parameters. Any suggestions?

R Code
df=dockerfile("simple_test_script_resources/simple_test.R", copy = "script_dir", cmd = CMD_Rscript("simple_test_script_resources/simple_test.R"))

Dockerfile:

FROM rocker/r-ver:3.3.2
MAINTAINER "matthiashinz"
COPY ["simple_test_script_resources", "payload/simple_test_script_resources/"]
COPY ["simple_test_script_resources/simple_test.R", "simple_test_script_resources/test_table.csv", "payload/simple_test_script_resources/"]
COPY ["simple_test_script_resources/test_subfolder", "payload/simple_test_script_resources/test_subfolder/"]
COPY ["simple_test_script_resources/test_subfolder/testresource", "payload/simple_test_script_resources/test_subfolder/"]
WORKDIR payload/
CMD ["Rscript", "--save", "simple_test_script_resources/simple_test.R"]

[nuest]

Why the --save option?

When you switch to the WORKDIR before all the copy statements, you only have to write "payload" once. Can you make that simplification?

I do not understand the issue with default parameters. Can you give examples?

[MatthiasHinz]

• The --save option saves all created R objects to RData... But well, since the container normally stops after execution, I can remove it either way...

• simplification should be no problem

• What I mean with default parameters (it's not an issue, it's a description):
  If I call docker run "myImageName" (or harbor::docker_run(...)), the container will execute the script according to the CMD statement and then terminate. But the docker run command can also override that statement, e.g. using docker run "myImageName" R or docker run "myImageName" /bin/bash

[MatthiasHinz]

Well, I figured out by testing that the following Dockerfile does exactly the same job (it also copies the subfolder and resources). Kind of strange, that this simple solution did not ocure to me in first place, even though I read the Dockerfile Documentation...

FROM rocker/r-ver:3.3.2
MAINTAINER "matthiashinz"
WORKDIR payload/
COPY ["simple_test_script_resources", "simple_test_script_resources/"]
CMD ["Rscript", "simple_test_script_resources/simple_test.R"]

[MatthiasHinz]

https://sysreqs.r-hub.io/
Seems to be down at the moment. I get 502 Bad Gateway
Edit: looks like they change something at the moment. I will check that tomorrow again.

[MatthiasHinz]

Shall we throw an error if the supplied script does not have an extension ".R" or just assume it is an R script if the extension is unknown?

What shall we do if the 'copy' parameter has a list of files and directories, but the R script is not included in this list? Do nothing?

[nuest]

Regarding extension: assume it is an R script, whatever the extension.

Regarding copy: then copy these files and directories. If the user things he knows better, he probably does.