Feature Idea: tar_files() works with a scalar character filename

[billdenney]

As you're probably noticing with all the activity from me about targets and now tarchetypes, I'm learning the conversion from drake to targets!

I just tried to use tar_files() on a single file to test it out, but I got an error, Error: callr subprocess failed: command must be a language object. I think that one of two things would be preferable:

1. tar_files() works with just a character scalar instead of requiring a language object. (My preference, but it could add unnecessary effort to code maintainability for a potentially low-value feature.)
2. The error in the case below for tar_files() were clearer that you should wrap the character string in c() (or whatever the preference is with another method).

Reprex (which will leave a file named "textfile.txt" on your system-- I don't know how to make a real reprex that will also clean up after itself for this one):

library(targets)
library(tarchetypes)

# Create a file for use
cat("foo", file="testfile.txt")

list(
  tar_files(
    filename,
    "testfile.txt"
  )
)

[ginolhac]

Hello,
I think you need tar_file() for a single file

library(targets)
tar_script({
  library(tarchetypes)
  # Create a file for use
  cat("foo", file="testfile.txt")
  
  list(
    tar_file(
      filename,
      "testfile.txt"
    )
  )
})


tar_make()
#> • start target filename
#> • built target filename
#> • end pipeline

^{Created on 2021-09-15 by the reprex package (v2.0.1)}

[ginolhac]

tar_files() creates a pair of upstream/downstream targets to dynamically iterate from

library(targets)
tar_script({
  library(tarchetypes)
  # Create a file for use
  cat("foo", file="testfile.txt")
  cat("foo", file="testfile2.txt")
  
  list(
    tar_files(
      filename,
      dir(pattern = "txt$")
    )
  )
})


tar_make()
#> • start target filename_files
#> • built target filename_files
#> • start branch filename_d80b4ef7
#> • built branch filename_d80b4ef7
#> • start branch filename_3bebc1ed
#> • built branch filename_3bebc1ed
#> • built pattern filename
#> • end pipeline
tar_read(filename)
#> filename_d80b4ef7 filename_3bebc1ed 
#>    "testfile.txt"   "testfile2.txt"

^{Created on 2021-09-15 by the reprex package (v2.0.1)}

[billdenney]

@ginolhac Thanks for the information above.

I have two reasons for the request related to tar_files().

My first reason is a simple one: The error message when using tar_files() didn't tell me much about what I was doing wrong. I guessed that it may require multiple files, tried adding a c() around the single file may help, and it did. If no change is made to tar_files() functionality, a clearer error message would help.

My second reason is to simplify the use case. I'm not sure why tar_files() needs to differ from tar_file(). I do understand that tar_files() generates a set of dynamic targets representing all of the files to allow for dynamic branching while tar_file() creates a single static target. These are conceptually different from the targets ecosystem perspective and from how individual targets are tracked within targets, but why cannot tar_files() also generate a single dynamic target from a single string input-- effectively wrapping the single string input as a single dynamic target?

The reason I wanted the second use case is because I often work with a set of files that are supposed to have the same structure-- but they don't always have the same structure. So, I like to get the code working with one file and add more files one-by-one. A simple work-around for this use case is to just wrap the filename in c() and it will work.

But, wrapping in c() seems like an odd requirement because without knowing that more complex parsing will occur on the command argument to tar_files(), I would assume that "filename" and c("filename") are the same as they are in most other parts of R.

Overall, my goal with this request is to make targets and tarchetypes more accessible to a wider range of R users. Now that I know the requirement for c(), I'll not have a problem, but it wasn't clear that it was required.

[wlandau]

Yeah, we should be able to put more trust in targets to check if the command argument can be understood as given. Bit of a Chesterton's fence here, but this is a simple enough problem. Try e4e5b8e.