rstudio / rsconnect

Publish Shiny Applications, RMarkdown Documents, Jupyter Notebooks, Plumber APIs, and more
http://rstudio.github.io/rsconnect/
134 stars 82 forks source link

`appmode` inferred incorrectly for multiple rmd files #19

Closed trestletech closed 9 years ago

trestletech commented 9 years ago

It sounded like the plan was to handle this in the IDE before we internally would call deployApp, but this sounded buggy to me.

It looks like this code presumes that if a directory has more than 1 Rmd file, then it must be a Shiny RMD: https://github.com/rstudio/rsconnect/blob/f59a6dfaf58b5f5b927606316c86ca03f1da4437/R/bundle.R#L79-L81

I had been deploying from a dir that happened to have two Rmds (though I was only interested in the index.Rmd, in this case) and couldn't get it to deploy as anything but a Shiny RMD.

Even if the IDE can do filtering to remove spurious Rmd files from the deployed dir, it is possible for Knitr to use child Rmd documents in a static mode (https://github.com/yihui/knitr/tree/master/inst/examples/child) so I think this is a legitimate use case.

jmcphers commented 9 years ago

Even if the directory contains multiple R Markdown docs, the IDE now just publishes the current one when you click Publish. This is new behavior added in the last few weeks and should greatly reduce the number of times we have to deal with this situation (inferring what's intended in the rsconnect package when a directory contains multiple Rmds).

It sounds like the behavior you're expecting is that we publish as Shiny RMD if any R Markdown document is a Shiny doc, and static otherwise. Is that right?

trestletech commented 9 years ago

Oh, cool. I don't know that I've updated in the past week or two.

It sounds like the behavior you're expecting is that we publish as Shiny RMD if any R Markdown document is a Shiny doc, and static otherwise. Is that right?

I'm not sure what I'm proposing/expecting, but I think that might be right. I guess I was anticipating that there would be an authoritative Rmd either gleaned interactively through the IDE or by assuming that it would be index.Rmd which would dictate the mode of the deployment. It would be surprising to me if I add a new Shiny Rmd in my directory to play around and then next time I deploy my (previously static) directory it suddenly becomes a Shiny Rmd.

I suspect that you have better insight into the various edge cases here, so I'm happy to defer the final decision to your judgement (though I'm happy to chat further about it, if you'd like), but I didn't have an ultimate solution in mind.

jmcphers commented 9 years ago

Yes, part of the recent IDE change is that we now pass a "primary" Rmd to the deployment from the IDE (which is the actual doc the user clicked Publish on). But this parameter is not required when publishing from the console, and so we can't guarantee its presence. Even if we used that as the "key" to determine whether the set of documents as a whole should be treated as Shiny, we'd create an equally nondeterministic situation, in which you get a different mode for your app depending on which of its multiple pages you happened to click Publish on.

What happens today to a Shiny doc if it's placed in an app marked static? Does it work at all?

At the end of the day if there's too much ambiguity in the filesystem we might have to have the user choose the desired mode in the IDE, and have the IDE pass that as another parameter to deployApp.

trestletech commented 9 years ago

A quick test suggests that a Shiny app in a static mode doesn't work.

This sounds like a good fix, so let's give it a shot and we can see if we get any feedback. Thanks for taking a look!