Runtime failure of deployed application from suggested package

[rstub]

I recently encountered the following runtime failure of an application deployed to Connect:

• A Shiny app was using the pins package to read a pin stored on Connect.
• This pin had been created using the parquet format.
• Therefore the arrow package was needed to execute the code.
• However, the arrow package was never mentioned explicitly in the code and therefore not included in the manifest.

One workaround is to add library(arrow) explicitly to the Shiny app. And I am not sure if it is possible to detect such run-time dependencies at deployment time (that would be the ideal solution). It would be helpful if the user could be informed about the fact that packages used in the application (i.e. part of the manifest) are suggesting some packages that seemingly are not used in the application (i.e. not in the manifest) but are installed in the local environment. I am undecided if this would be better during the deployment or as the result of a separate function call.

[aronatkins]

In the abstract, this feels difficult to get right. The data format of the target pin could change over time, and you might locally test against data that is in a different format from what the deployed code sees. Additionally, you may not have access to the target location from the deploying host.

Does the deployed pin expose its runtime requirements? That feels like a place we could start, since the pins package should know the format of the data it is storing.

https://github.com/rstudio/pins-r/blob/b8827ac2d61cda526d01a9a4db57af4d4108bceb/R/board_connect_bundle.R#L54-L79
https://github.com/rstudio/pins-r/blob/b8827ac2d61cda526d01a9a4db57af4d4108bceb/inst/preview/index.html

@juliasilge and @kevinushey - do you have any thoughts about this? Could renv-dependency-scanning and pins somehow expose the library requirements for consumed pins data?

[juliasilge]

We have added documentation as well as a method to help with the fact that a board can require packages. For example, notice the 4th bullet here and the required_pkgs method. (The vetiver package uses this infrastructure to figure out what packages to use when deploying a model.)

We haven't done much yet about the fact that a pin can require packages. We do store the file type in the pin metadata, like type: rds here, so that would be available for dependency scanning.