Non-default alternative import paths, should we keep them?

[chainsawriot]

• import("x.csv", fread = FALSE) -> utils::read.table
• import("x.txt", format = "fwf", readr = TRUE) -> readr::read_fwf (not in Suggests)
• import("x.dta", haven = FALSE) -> foreign::read.dta
• import("x.sav", haven = FALSE) -> foreign::read.spss
• import("x.xpt", haven = FALSE) -> foreign::read.xport
• import("x.xlsx", readxl = FALSE) -> openxlsx::read.xlsx see also Switch from openxlsx to writexl #310

Potential impact: boxr (r-box/boxr) lists all of them in their doc

https://github.com/r-box/boxr/blob/608f02ec43a56d3af96b049c72e081543f06b511/R/boxr_read.R#L1-L41

Also uses like

https://github.com/opentargets/mendelian-randomisation/blob/85ab9d121bda40d2173a95b305bd5fb7635bef18/ensid_maps/creating_metabolite_ensid_maps/metab_2.R#L19

https://github.com/yonicd/typeR/blob/66e6996f31961bc8b9aafe1a6a6098327b66bf71/data/genthat_extracted_code/dataverse/examples/files.Rd.R#L34

By Thomas Leeper

https://github.com/jamesdunham/dataverse-client-r/blob/096d85ed0ef586825efb9586f5f8f6c7cd61410b/R/get_file.R#L37

https://github.com/leeper/designcourse/blob/1bf40b9d5731ff77dc53df3998257f86dadb716b/Assignments/Lab4.tex#L44

https://github.com/leeper/Rcourse/blob/884b83976ff19c7b887547d841d260d87165797b/Data/CusackIversenSoskiceAPSR2007.R#L4

[chainsawriot]

If they are not needed, we can still keep the parameters (for a while, maybe until the next major version e.g. v2.0); but mark them as deprecated (using lifecycle and give warnings), and use the default path.

[chainsawriot]

@ijlyttle May I have your opinion on this? How would that impact boxr? Thank you very much!

[schochastics]

I would love to hear from someone how removing this feature could break something. I think this could be dropped and internally handled without too much effort and I am very much in favor of doing that (given that there really is no use case I am missing)

[ijlyttle]

Hi all,

I have not been able to pay proper attention to boxr lately (hoping to get back to it), as my company has moved away from Box.

I remember a conversation with @nathancday (boxr co-maintainer), where we discussed how tightly bound boxr::box_read() is with rio::import(). I think our conclusion was that, if writing from scratch, we would not do it that way, but that we have an obligation not to break stuff - it sounds like you are having a similar conversation.

I don't (and didn't) use box_read() myself, and I don't really have a good feel for how it's used out in "the wild". That said, I have a sinking feeling that despite the deprecation warnings, we would find out afterwards...

From a coding standpoint, for boxr, I think it would be a matter of updating the documentation to advertise any new behavior from rio.

Of course, I'd want to hear what @nathancday might have to say (Hi Nate, it's been too long!)

[chainsawriot]

There is also one non-default export path

• export(x, "hello.csv", fwrite = FALSE) -> utils::write.table

The alternative path for xlsx is removed in #359

[chainsawriot]

With #359, we have a template for removing these paths

.import.rio_sav <- function(file, which = 1, haven = lifecycle::deprecated(), to.data.frame = lifecycle::deprecated(), use.value.labels = lifecycle::deprecated(), ...) {
    if (lifecycle::is_present(haven) || lifecycle::is_present(to.data.frame) || lifecycle::is_present(use.value.labels)) {
        lifecycle::deprecate_warn(when = "0.5.31", what = "import(haven)", details = "sav will always be read by `haven`. The parameter `haven` will be dropped in v2.0.0.")
    }
    standardize_attributes(haven::read_sav(file = file))
}

[schochastics]

@chainsawriot I could take over this task if you dont mind

[chainsawriot]

@schochastics Please! I will focus on the ....

[chainsawriot]

• PR r-box/boxr on those removed options in the doc Update doc fix #242 r-box/boxr#243

I will do that.