Warn when Shiny app has a DESCRIPTION file

[jmcphers]

Repro:

1. Create a Shiny application which uses a library not part of Shiny, such as library(plumber)
2. Add to its directory a DESCRIPTION file which looks like a package's DESCRIPTION file
3. Publish the application

The application publishes, but doesn't work on the server since it's missing the plumber library.

Here's an example DESCRIPTION that's known to be problematic:

Package: placeholder
Title: Does not matter.
Version: 0.0.1
Imports: bookdown
Remotes: rstudio/bookdown

The problem is that when there's a DESCRIPTION file, packrat uses the packages named in that file instead of scanning the code for dependencies. This happens in packrat here:

https://github.com/rstudio/packrat/blob/f29ca870a6254859de034b7a811f31f5e9caa4bc/R/dependencies.R#L55-L81

We could fix this in a couple of ways:

1. Omit DESCRIPTION from the directory while packrat is scanning the directory.
2. Add a flag (or environment variable, etc.) to packrat's snapshot that indicates that the directory should not be treated as a package even if it looks like one.

[jjallaire]

The DESCRIPTION file has a Type field which should be used here (if no Type is specified then Package is assumed). Once the Type field is added this should no longer occur

…

On Fri, Jul 21, 2017 at 3:58 PM Jonathan ***@***.***> wrote: Repro: 1. Create a Shiny application which uses a library not part of Shiny, such as library(plumber) 2. Add to its directory a DESCRIPTION file which looks like a package's DESCRIPTION file 3. Publish the application The application publishes, but doesn't work on the server since it's missing the plumber library. Here's an example DESCRIPTION that's known to be problematic: Package: placeholder Title: Does not matter. Version: 0.0.1 Imports: bookdown Remotes: rstudio/bookdown The problem is that when there's a DESCRIPTION file, packrat uses the packages named in that file instead of scanning the code for dependencies. We could fix this in a couple of ways: 1. Omit DESCRIPTION from the directory while packrat is scanning the directory. 2. Add a flag (or environment variable, etc.) to packrat's snapshot that indicates that the directory should not be treated as a package even if it looks like one. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#192>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGXx27eufBd1VXbxNM1A1AwekNnBt8eks5sQQLEgaJpZM4Of0_0> .

[jmcphers]

Unfortunately the DESCRIPTION here is from a printed copy of the bookdown book (see https://bookdown.org/yihui/bookdown/github.html), so anyone copying from that example is going to run into trouble.

[jjallaire]

Ah, bummer! Perhaps Travis should be made smarter about accepting alternate Type fields in the DESCRIPTION.

…

On Fri, Jul 21, 2017 at 4:14 PM, Jonathan ***@***.***> wrote: Unfortunately the DESCRIPTION here is from a printed copy of the bookdown book (see https://bookdown.org/yihui/bookdown/github.html), so anyone copying from that example is going to run into trouble. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#192 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGXxwmekOnUJLOPyWxMPffYeJxoUlBvks5sQQakgaJpZM4Of0_0> .

[kevinushey]

The example has since been updated to use Type: Book, and that appears to work fine on Travis, so I think this should imply that the issue is resolved. In general, projects that use a DESCRIPTION file that don't want to appear like an R package to Packrat need to explicitly set the Type: field.

[koverholt]

Ran into this today with a user publishing a Shiny app to RStudio Connect.

Symptoms were that app.R was sometimes not included in the app bundle, or errors such as Warning: Error in library: there is no package called ‘feather’

Removing the DESCRIPTION file from the project dir worked.

Could rsconnect warn when this file is present?

[hadley]

IMO the current behaviour is correct, because we want to give people the ability to explicitly specify package dependencies with a DESCRIPTION file. But we need to make it more clear when this behaviour is used, and how to change it.

[hadley]

This is no longer an issue because we set options("packrat.dependency.discovery.renv" = TRUE), and renv combines packages from the DESCRIPTION with packages discovered elsewhere.