Remove dependency on purrr in favor of standalone-purrr

[khusmann]

Something you may want to consider -- I've found that many tidyverse packages will drop in a "import-standalone-purrr.R" file instead of directly depending on purrr.

Here's the source in rlang: https://github.com/r-lib/rlang/blob/main/R/standalone-purrr.R

Here's what it looks like imported into vctrs (for example): https://github.com/r-lib/vctrs/blob/main/R/import-standalone-purrr.R

usethis even includes a function for importing / managing these kinds of standalone imports: https://usethis.r-lib.org/reference/use_standalone.html

I haven't found much more explicit documentation regarding this practice, but it seems like a nice way to locally embed this kind of core functionality without having to subscribe to the more heavyweight features of a package (and gives you one less dep to track for API changes). I'm giving it a try in my interlacer package.

I did a quick scan and it appears that all of purrr's functionality you're currently using in frictionless-r is present in the standalone purrr, so it'd be a drop in replacement and should work out of the box.

[PietrH]

Are purrr::chuck() and purrr::pluck() missing from standalone purrr?

[khusmann]

Correct, the standalone version does not come with pluck() and chuck()

[peterdesmet]

Thanks for investigating @khusmann! We do rely on pluck() and chuck() (especially in tests), so let's stick with a direct import of purrr for now. It is part of tidyverse, has 5 dependencies (cli, lifecycle, magrittr, rlang, vctrs) which we are all familiar with and we haven't encountered API changes so far.