Request: Generic `drop_read` function
- Dominant language
- R
- Stars
- 253
- Forks
- 60
- PR merge metrics
- No merged PRs in 30d
Description
I think `drop_read_csv` defines a really useful pattern: `drop_get` to a local tempfile, then use `read.csv` on it. There's a hard limitation on `read.csv`; if I want to use, say `readr::read_csv`, I have to re-implement the function changing just that last line (and adding `rdrop2:::` to the dtoken arg).
I do this a lot, and I suspect it'd be helpful to others to make this easier and enforce good usage.
How about a function `drop_read` that looks roughly like this?
```r
drop_read <- function(file, function, dest = tempdir(), dtoken = get_dropbox_token(), ...) {
localfile = paste0("dest, "/", basename(file))
drop_get(file, local_file = localfile, overwrite = TRUE, dtoken = dtoken)
function(localfile, ...) # maybe rlang::as_function?
}
```
There's no real reason this has to be _read_-specific, so it could be named something more generic; `drop_do`? Then `drop_read_csv` could be a slim wrapper around this new thing.
I'd be happy to file a PR, but I know @karthik is in the middle of API v2 refactoring and I don't want this to get lost in the shuffle.
**(p.s. Karthik I'd love to help with that refactoring, just not sure where you're at or what the plan is)**
Contributor guide
Research direction
Start by locating the existing drop_read_csv and drop_get entry points, then check how the API v2 refactoring affects their interfaces. The issue does not name files or tests; done would mean agreeing on a generic callable pattern, handling the token and temporary-file flow, and determining whether drop_read_csv becomes a wrapper.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- r
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100