Closed layik closed 3 years ago
Current thoughts are:
Premise: Windows does not
kill child processes when their parents die. Based on this:
nohup
or similar FOR Unix and use nothing on Windows to run background processes for npm start
.plumber
blocking to the last command.That way, if front is needed either in the background with backend or on its own. And the backend takes priority as it also is the better/production env as it serves what the front dev server serves.
Experimental solution to this is what gp_map
uses. Bypass the whole webpack/transpiling issues discussed in #81
R package future
was not useful or not used correctly see #58 and others.
Thanks @mpadge this is useful, I must have not used callr::r_bg
in the past properly. If list
params is not passed the plumber process exits I think.
Thanks again.
Gives me great pleasure to share first ever reprex
of geoplumber:
library(geoplumber)
d <- file.path(tempdir(), "gp")
gp_create(d)
#> Creating directory: /var/folders/z7/l4z5fwqs2ksfv22ghh2n9smh0000gp/T//RtmpBelYrg/gp
#> To build/run app, set working directory to: /var/folders/z7/l4z5fwqs2ksfv22ghh2n9smh0000gp/T//RtmpBelYrg/gp
#> Standard output from create-react-app works.
#> You can run gp_ functions from directory: /var/folders/z7/l4z5fwqs2ksfv22ghh2n9smh0000gp/T//RtmpBelYrg/gp
#> To build the front end run: gp_build()
#> To run the geoplumber app: gp_plumb()
#> Happy coding.
setwd(d)
ps <- gp_plumb()
#> WARNING:
#> Looks like geoplumber was not built, serveing API only.
#> To serve the front end run gp_build() first.
ps
#> PROCESS 'R', running, pid 1419.
Sys.sleep(1) # just in case
ps
#> PROCESS 'R', running, pid 1419.
require(RCurl)
#> Loading required package: RCurl
webpage <- getURL("http://localhost:8000")
webpage <- readLines(tc <- textConnection(webpage)); close(tc)
tail(webpage)
#> [1] " <p>build missing</p>" " </div>"
#> [3] "</div>" ""
#> [5] "</body>" "</html>"
ps$kill()
#> [1] TRUE
Created on 2020-05-17 by the reprex package (v0.3.0)
Amazing timing - I'm grappling with exactly those issues in another repo right now, trying to get callr::r_bg()
to properly serve a plumber instance. I'll check out what you've done asap. Great to see you back @layik
Hi Mark, got the insight from that repo, report package or something, I thought I had put a link in the above comment.
Yes, must get geoplumber out!
I don't know why but devtools::test()
test call to callr::r_bg()
generates too many "Unable to find env file..." error which is hitting this bit. When doing R CMD Check
that does not happen. Strange!
Yeah, the env
stuff is exactly what i need to spin up tomorrow to get my stuff working. I need to stick variables in the local (non-R) environment, and then read them in via the background process. That's one of my tomorrow morning tasks, so I'll have a look at your code at the same time, and ping when i've got a solution.
@layik I managed to fix my errors, mostly by using the debugging abilities of callr
via stuff like this:
ps <- callr::r_bg (f, list (r = r,
port = as.integer (port)),
stdout = "/tmp/out",
stderr = "/tmp/err")
Notes:
as.integer(port)
is really important, because trying to $run(port = port)
a plumber object will fail if port
is not an integerstdout
and stderr
dump all logging info to those /tmp
files which can then be inspected to work out what's going wrong.Thank you very much Mark, I take it you didn't (thankfully) hit the 'No environment file in temp dir' error.
I will note these as they are too precious and who knows might save me days.
No, but stuff i'll be doing today will involve passing envvars through, but r_bg
has it's own env
list that is passes anyway (callr::rcmd_safe_env()
), so you can easily just add whatever you want to that, and pass it as the env
par instead of the default.
Missed this comment, thanks Mark.
I think I need to get to know the package better so again your insights will come handy. callr
has solved a huge hurdle for the package, though not had a chance to work on it this week.
Reopen if this is needed.
At the moment, there is no strategy to start both separately without one blocking the other.
Plumber uses ... (will fill that gap later) to start the backend server. And
npm start
does the front end, which is a blocking command.At least on macOS cannot be sent to the back with say
system("npm start &)
orsystem("npm start", wait = FALSE)
. Though works fine if continues to block which makes impossible for backend to run.S needs better
system
andsysteme2
understanding or more from R. Relevant functions are:gp_plum
andgp_plumb_front
. Of course, in the shell, always done it in two different windows (tmux or not).