Make upload.fun configurable via option

[wlandau]

As much as I love automatic image embedding in reprex, it does present a challenge for those of us collaborating on confidential projects in a locked-down industry setting. My own company's proxies do not block the uploads, and the URLs are public. We would still like to share rendered reprexes in our internal private repos.

[jennybc]

This example shows how to override upload.fun, in this case forcing the fig to stay local:

https://github.com/tidyverse/reprex/blob/de45a371e3356371fa092a2c927592a6793a25f0/R/reprex.R#L176-L188

With that in mind, what are you thinking?

[jennybc]

If specifying upload.fun in the reprex code is unattractive (which I can imagine), the options would seem to be ... putting this under the control of an option (meh) or allowing a custom reprex template (?). I used to expose the knitr options more, but got no sense that anyone ever used it and removed that.

[wlandau]

That example definitely helps, and I personally think calling knitr::opts_knit$set(upload.fun = identity) is not too much to ask. But maybe some guidance on the usage of upload.fun and other knitr options would be nice, with cross-references alongside mentions of Imgur.

[jennybc]

I'm highjacking your issue @wlandau.

Note to self: wrap upload.fun and put the logic about doing different things for different venues inside it. Then make that something that is configurable via option. Default behaviour for general population stays the same but people like @wlandau can re-configure and we could share a recipe that helps people in China and can't use imgur.com (see the ending of the #220 saga).

[wlandau]

Thanks, @jennybc!

[jennybc]

Also related to #259 re: making the options better documented.

[jennybc]

I should announce here that, now that the big transition to a proper Rmd document format + reprex_render() is done ... there is no remaining technical blocker here. It's a matter of me (or someone else) figuring out how to execute this.

[cderv]

Adding some context about how knitr can be configured using R options for some of its package level options.

Currently overriding upload.fun for a reprex suppose to set hooks

knitr::opts_knit$set(upload.fun = identity)

Package level option can be set not just by hooks, but also using R options. So setting options(knitr.package.upload.fun = ) is way to set configuration global for knitr.

Thought, I believe in reprex context, this may not work, as reprex will overwrite the config by setting opts_knit$set(upload.fun = ) .

https://github.com/tidyverse/reprex/blob/651f5ef7cbb86ab2c8f51af52d37311612196c73/R/reprex_document.R#L73-L78

Checking this R option would be a way for reprex to not overwrite and respect it when this is set in session. So a way to configure the behavior without it being reprex specific.

The option is not set by default in knitr, this is just a way to globally configure knitr options (e.g. in .Rprofile) It is documented in ?knitr::opts_knit.

[idavydov]

I would like to comment on this from the perspective of an R developer working for a large company (100k+ employees).

It would partially help to have a configurable option. But we probably have a dozen of R/Rstudio deployments and making sure that this option is set everywhere is a challenging task on its own.

I think there is an implicit expectation by users that most functions will not upload any data from memory to a public server without any confirmation prompt. There are, of course, exceptions; like a function which could be called upload.something().

Generally speaking:

• reprex is a very popular package which is used to share reproducible code in all sorts of contexts.
• That is quite an unexpected behavior for a function which is not dedicated to data uploads and doesn’t have this in the signature. All the experienced R users I talked to were surprised by this behavior. I think it’s not a best practice in terms of usability.
• This is especially dangerous for companies which work with sensitive data (so could be a security issue).
• It is rather challenging to delete an image once it’s uploaded.

So we would be very much in favor of introducing some kind of warning/prompt before data is irreversibly leaked to the outside.

One of the potential counterarguments is that sensitive data can be only accessed in validated environments where reprex should be forbidden. In reality, however, that is not true. There are many contexts in which users work with private data which is not intended to be shared with the world (academic researchers, data scientists working with financial data, private individuals doing home budgeting and so on).

[idavydov]

P.S. The reprex function is described as "Run a bit of R code using rmarkdown::render() and write the rendered result to user's clipboard", it's very unclear from this description that anything will be uploaded to a public server without a straightforward mechanism to delete this after.