Run Application contained in a package

[Nicola Sturaro Sommacal]

Hi everybody.

I think the best way to distribute R code is an R package. This regards Shiny Application, too.

So, my question is: how to run in a Shiny Server an App that is contained in a package (without copying the app.R file, of course)?

I know I can configure the server for looking for application in the library of my package. Other ways?

Thank you,

Nicola

[Nicola Sturaro Sommacal]

Anyone? :)

[Joe Cheng]

Create a directory for the app just like normal. Add an app.R file that contains simply this line:

shiny::shinyAppDir("relative-path-to-appdir-within-inst", system.file(package = "yourpackage"))

I *believe* that should work.

--
You received this message because you are subscribed to the Google Groups "Shiny - Web Framework for R" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shiny-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/f7457752-3f18-4e2f-ae84-522043707990%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nicola Sturaro Sommacal]

First of all, thank you!

My app is in the root of inst, so shiny::shinyAppDir(system.file(package = "mypackage")) works.

If my package was not in the root of inst, I think the correct syntax should be: shiny::shinyAppDir(system.file("relative-path-to-appdir-within-inst", package = "mypackage"))

Thanks again.

Nicola

-- 
Nicola Sturaro Sommacal

mobile: (+39) 370 718 32 71

[Joe Cheng]

Yeah you're right, I misspoke.

[Dean Attali]

Using `runApp()` instead of `shinyAppDir()` will not work, correct?  Because runApp actually runs an app while shinyAppDir simple creates the shiny app object?  I want to see if I understand that correctly

[Joe Cheng]

Yes. runApp will be called by Shiny Server to even get to this point--so if you call runApp inside of app.R it'll be a nested call which never works.

To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/4a7141e9-0ef4-4069-bb4d-31949219817e%40googlegroups.com.

[Nicola Sturaro Sommacal]

I try to summarize:

• shinyApp creates the app
• shinyAppDir "addresses" to a dir containing a shinyApp
• runApp runs a local Shiny Server. This is required only when launching an app locally (not Shiny Server)

Right?

-- 
Nicola Sturaro Sommacal

mobile: (+39) 370 718 32 71

[Dean Attali]

Hi Joe,

I just tried doing what this thread originally asked: serving a shiny app that's inside an installed package by just creating an app.R file that contains "shiny::shinyAppDir(system.file(...))".  It looks like it doesn't work if the shiny app loads any other files. If it sources a file or uses CSS or includes any external file, I get "ERROR: cannot open the connection". Is there a solution to this?

The only solution I can think of is creating a symlink but I really don't want to do that, I'm hoping there's a solution in Shiny for this

[Joe Cheng]

Call setwd() to the app's path before returning shinyAppDir? That'd be pretty poor form to do to someone's interactive R session, but in a shiny server scenario it's fine.

[Dean Attali]

You're right, that's a very simple solution, thanks

[Parth Khare]

Hi,

Background:

I have been facing a similar problem. I am using a markdown script to publish an app.R.

The app.R has already been registered onto shinyapps server. However, using shinyAppDir within the markdown code is not getting published.

Already attempted:

1.) shinyAppDir was not working with system.file [     

   shinAppDir(system.file("C:/Folder/With/App/File), package = shiny", options = list(..))

     Therefore, I tried 

   shinAppDir(system.file("C:/Folder/With/App/File), package = shiny", options = list(..))

This atleast helped me preview the Markdown document on console, but I was not able to publish it.

2.) The error which kept on popping up was: No shiny application exists at C:/Folder/With/App/File

I checked made sure the that working directory contains Rmd, app.R and the associated dataset are in the same folder. 

3.) It seemed that the path defined in shinyAppDir was stopping it from letting it publish

Therefore, I tried running the entire app.R within the markdown Rmd file itself. This did not work as well

4.) I am thinking finally on the lines of somehow directing to shinyAppDir after setting working directory with all the files.

Kindly help have almost tried every imaginable permutation 

[Joe Cheng]

Don't use system.file. Just pass a *relative* path to your Shiny app dir (or since you have app.R, you can use shinyAppFile and use a relative path to the app.R file itself).

--
You received this message because you are subscribed to the Google Groups "Shiny - Web Framework for R" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shiny-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/e46dcfc6-2a2a-49e4-8f4b-b2f6be6fb6d9%40googlegroups.com.

[Parth Khare]

Thank you Joe!

I am not using system.file(), I have been using relative paths only.

I intially tried with shinyAppDir (getwd, options = list()). But it did not work.

So, I moved to using shinyAppFile as well with relative path but again I could not publish.

The reported error with shinyAppFile was : "Error path [1]: "app.R" No such file or directory

Have attached a sequential list of syntax tried so far:

```{r tabsets, echo=FALSE}

# --------- Method 1: [app.r by 'source' + shinyApp ] ---------#

# setwd("C:/Parth/Personal/Data Mining/sociocaRtography/Delhi/Sessions/DelhiCrimePost")

# source("C:/Parth/Personal/Data Mining/sociocaRtography/Delhi/Sessions/DelhiCrimePost/app.R")

# shinyApp(ui, server)

# --------- Method 2: [app.R by Actual file path + shinyAppDir] ---------#

# shinyAppDir("C:/Parth/Personal/Data Mining/sociocaRtography/Delhi/Sessions/DelhiCrimePost",

# # package = "shiny"),

#   options = list(

#     width = "100%", height = 550

#   )

# )

# --------- Method 3: [getwd() + shinyAppDir] ---------#

# shinyAppDir(getwd(),

# # package = "shiny"),

#   options = list(

#     width = "100%", height = 550

#   )

# )

# --------- Method 4: [setting Working directory + shinyAppDir    ] ---------#

#sys <- "C:/Parth/Personal/Data Mining/sociocaRtography/"

#setwd(paste0(sys, "Delhi/Sessions/DelhiCrime"))

#shinyAppDir(paste0(sys, "Delhi/Sessions/DelhiCrime"), #package = "shiny"),

#  options = list(

#    width = "100%", height = 550

#  )

#)

# --------- Method 5: [setting Working directory(relative path) + shinyAppFile    ] ---------#

# setwd("C:/Parth/Personal/Data Mining/SociocaRtography/Delhi/Sessions/DelhiCrimePost")

shinyAppFile("app.R",options = list(width = "100%", height = 550))

```

PS: The folder "C:/Parth/Personal/Data Mining/SociocaRtography/Delhi/Sessions/DelhiCrimePost"

contains the R markdown document, app.R and the dataset used by app.R

Thank you again for your help and feedback!

To unsubscribe from this group and stop receiving emails from it, send an email to shiny-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/e46dcfc6-2a2a-49e4-8f4b-b2f6be6fb6d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

------------------------------------------------------------------------------------------------------------
Parth Khare | Data Scientist | Mobile: +91 9868485655 |
Photo-stream: https://www.flickr.com/photos/112535056@N08/

[Parth Khare]

[Barry Rowlingson]

On Thursday, September 24, 2015 at 5:54:02 PM UTC+1, Joe Cheng [RStudio] wrote:

Create a directory for the app just like normal. Add an app.R file that contains simply this line:

shiny::shinyAppDir("relative-path-to-appdir-within-inst", system.file(package = "yourpackage"))

I *believe* that should work.

Running this way doesn't seem to run the code in global.R - so my boilerplate app.R for shiny server deployment looks like this:

path = system.file("shiny/appname",package = "mypackage")
source(file.path(path,"global.R"))
shiny::shinyAppDir(path)

although I suspect the real solution is to factor the code in global.R out. Is global.R considered harmful?

[Dean Attali]

I believe that global.R is supposed to be fine (since it's an intended feature to use) and that it's a bug that shinyAppDir doesn't recognize it.  I did open a bug report about it a while ago See https://github.com/rstudio/shiny-server/issues/180

---

http://deanattali.com

--
You received this message because you are subscribed to a topic in the Google Groups "Shiny - Web Framework for R" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/shiny-discuss/ibAXs3zLWAs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to shiny-discuss+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/969b0482-8d34-40df-a35f-1ef7de230b97%40googlegroups.com.

[Joe Cheng]

Parth, the last one should've worked. Can you zip up that folder and send it to me so I can reproduce?

Dean, Barry, this may be misguided but I left global.R support out of shinyAppFile/shinyAppDir because I thought it was a bad idea to have multiple, relatively independent Shiny apps that run concurrently, to all make changes to the global environment. Especially since the single-file app.R style lets you declare variables that are accessible in both ui and server, but do not pollute the global environment.

Clearly it's a surprising behavior though. What do you think of the following alternatives:

1) Run global.R, let it modify the global environment, don't worry about collisions between different subapps

2) Run global.R but not in the global environment, just in an environment that ui.R and server.R (or app.R) inherit. I like the semantics but don't like that it's titled "global.R" and isn't global.

3) Don't run global.R, but if one is detected, emit a warning that it will be ignored

On Wed, Aug 17, 2016 at 9:47 AM Dean Attali <daat...@gmail.com> wrote:

I believe that global.R is supposed to be fine (since it's an intended feature to use) and that it's a bug that shinyAppDir doesn't recognize it.  I did open a bug report about it a while ago See https://github.com/rstudio/shiny-server/issues/180

---

http://deanattali.com

On 17 August 2016 at 08:52, Barry Rowlingson <b.rowl...@gmail.com> wrote:

On Thursday, September 24, 2015 at 5:54:02 PM UTC+1, Joe Cheng [RStudio] wrote:

Create a directory for the app just like normal. Add an app.R file that contains simply this line:

shiny::shinyAppDir("relative-path-to-appdir-within-inst", system.file(package = "yourpackage"))

I *believe* that should work.

Running this way doesn't seem to run the code in global.R - so my boilerplate app.R for shiny server deployment looks like this:

path = system.file("shiny/appname",package = "mypackage")
source(file.path(path,"global.R"))
shiny::shinyAppDir(path)

although I suspect the real solution is to factor the code in global.R out. Is global.R considered harmful?

--
You received this message because you are subscribed to a topic in the Google Groups "Shiny - Web Framework for R" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/shiny-discuss/ibAXs3zLWAs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to shiny-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/969b0482-8d34-40df-a35f-1ef7de230b97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "Shiny - Web Framework for R" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shiny-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/CA%2Bj8Z%2BkekJgKB85j9s8UnYTr5KtOG4F_esSpg84_BR7w9aU-FQ%40mail.gmail.com.

[Dean Attali]

I probably just don't understand how global.R works. I always just assumed that it's a file that gets automatically "sourced" by both ui and server before the app starts, and that's it. I thought that sourcing global.R manually is equivalent.  But based on your concern of having multiple apps contaminating a single global env, that suggests that somehow the global.R is NOT tied to only the app in its directory?  I never really gave any thought to the name "global" and didn't realize it literally is modifying the global environment, I thought it was only modifying an environment within "shinyApp()". I suppose I personally vote for option #2 the most because that's the thinking I was operating under this whole time. I think the name is still fine - it's not global in the sense that it's modifying the global env, but it's global in terms of the current shiny app, if that makes sense.

---

http://deanattali.com

On 17 August 2016 at 11:40, Joe Cheng <j...@rstudio.com> wrote:

Parth, the last one should've worked. Can you zip up that folder and send it to me so I can reproduce?

Dean, Barry, this may be misguided but I left global.R support out of shinyAppFile/shinyAppDir because I thought it was a bad idea to have multiple, relatively independent Shiny apps that run concurrently, to all make changes to the global environment. Especially since the single-file app.R style lets you declare variables that are accessible in both ui and server, but do not pollute the global environment.

Clearly it's a surprising behavior though. What do you think of the following alternatives:

1) Run global.R, let it modify the global environment, don't worry about collisions between different subapps

2) Run global.R but not in the global environment, just in an environment that ui.R and server.R (or app.R) inherit. I like the semantics but don't like that it's titled "global.R" and isn't global.

3) Don't run global.R, but if one is detected, emit a warning that it will be ignored

On Wed, Aug 17, 2016 at 9:47 AM Dean Attali <daat...@gmail.com> wrote:

I believe that global.R is supposed to be fine (since it's an intended feature to use) and that it's a bug that shinyAppDir doesn't recognize it.  I did open a bug report about it a while ago See https://github.com/rstudio/shiny-server/issues/180

---

http://deanattali.com

On 17 August 2016 at 08:52, Barry Rowlingson <b.rowl...@gmail.com> wrote:

On Thursday, September 24, 2015 at 5:54:02 PM UTC+1, Joe Cheng [RStudio] wrote:

Create a directory for the app just like normal. Add an app.R file that contains simply this line:

shiny::shinyAppDir("relative-path-to-appdir-within-inst", system.file(package = "yourpackage"))

I *believe* that should work.

Running this way doesn't seem to run the code in global.R - so my boilerplate app.R for shiny server deployment looks like this:

path = system.file("shiny/appname",package = "mypackage")
source(file.path(path,"global.R"))
shiny::shinyAppDir(path)

although I suspect the real solution is to factor the code in global.R out. Is global.R considered harmful?

--
You received this message because you are subscribed to a topic in the Google Groups "Shiny - Web Framework for R" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/shiny-discuss/ibAXs3zLWAs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to shiny-discuss+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/969b0482-8d34-40df-a35f-1ef7de230b97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Shiny - Web Framework for R" group.

To unsubscribe from this group and stop receiving emails from it, send an email to shiny-discuss+unsubscribe@googlegroups.com.

[Joe Cheng]

source("foo.R") always modifies the global environment by default (unfortunately)--you have to pass local=TRUE or local=env to get it to do something different.

I guess the number of cases where people actually expect/desire for global.R to modify THE global environment is probably pretty small...?

To unsubscribe from this group and all its topics, send an email to shiny-discus...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/969b0482-8d34-40df-a35f-1ef7de230b97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Shiny - Web Framework for R" group.

To unsubscribe from this group and stop receiving emails from it, send an email to shiny-discus...@googlegroups.com.

[Dean Attali]

Ah yes you're right, sourceing does modify globalenv, I suppose I just naively didn't think of the exact behaviour that happens when I have a shiny server running multiple apps and each app has its own global.R that it sources. I agree people generally don't think "I want to modify THE globalenv", it's probably a lot more of "I want to have some functions/data run before the app starts and share it across the app" 

[Joe Cheng]

Just to be clear, it's not Shiny Server running multiple apps that's the problem--generally, all those different apps each run in their own process (or processes). Yikes, it would be total chaos otherwise.

It's the fact that you can compose multiple apps into a single app using shinyAppDir and shinyAppFile (by incorporating them into the UI of an app, or embedding them from inside a Shiny Rmd document), where there can potentially be a problem, because then those sub-apps all do run in the same process.

To view this discussion on the web visit https://groups.google.com/d/msgid/shiny-discuss/515eed03-c152-43c0-9f9a-90313999f88e%40googlegroups.com.

[Parth Khare]

Hi Joe,

Please find the folder attcahed herewith, detials:

• app.R : Shiny application code 
• CrPpTwvrn_v2: R workspace with requisite data sets for app.R
  
• dlcrm.Rmd: Markdown script used to deploy shiny application with note

Further, I am deploying the code on the following shiny account, 'sociocartography'.

Again, the problem I am facing is that I am unable to publish the R markdown documentation of my shiny app.

All the Methods 1-4 (line #19 to line #52) are showing the desired output but it is not geeting deployed/published.

Much appreciate your help on this.

[Joe Cheng]

I'll try to take a look tomorrow

[Joe Cheng]

Thanks for your patience, Parth.

If you're publishing to shinyapps.io, the current method you're doing is correct (shinyAppFile("app.R"), without calling setwd first) but can you rename app.R to something else--like subapp.R? (And make the corresponding change to the shinyAppFile call as well, of course--e.g. shinyAppFile("subapp.R")) Oh, and you may also want to rename your Rmd file to index.Rmd, though I'm not 100% sure that's necessary.

I think what's happening is that the presence of app.R makes shinyapps.io treat the whole directory/project as a Shiny app with app.R at the top, rather than an Rmd document.

[Parth Khare]

Hi Joe,

This is incredible, it's finally working!

Do excuse the over elation, but It's just been such an ordeal figuring this out, esp at the last step :) 

Thank you so much for your assistance and patience on this.

[xhd...@umd.edu]

I found this discussion in reading a question in stackoverflow.

I strongly support the option 2. For the naming inconsistency, how about define a shared.R for this usage? So the global.R is still supported but deprecated, and new code are encouraged to use shared.R.

This is another example of why naming things is hard. As an off topic note, I found the naming inside NS are confusing too (I don't think it worth a separate post so I'm just ranting here)

> NS

function (namespace, id = NULL) 

{

    if (missing(id)) {

        function(id) {

            paste(c(namespace, id), collapse = ns.sep)

        }

    }

    else {

        paste(c(namespace, id), collapse = ns.sep)

    }

}

In the article of module, the usage of NS(id) actually means NS(namespace = id, id = NULL). It's fortunate that this happened behind scene and didn't confuse the reader. I think NS(module_id, internal_id = NULL) and csvFileInput <- function(module_id, label = "CSV file") would be better.