Install webppl in a better location

[hawkrobe]

As discussed with Mike Frank, installing in home might be causing some issues (including permissions or execution paths in R).

Other options include /Library/R/xxx/library/rwebppl (with the package itself) or /usr/bin -- should maybe see how other packages handle this?

[mikabr]

What do you mean by issues with "execution paths in R"? Installing in the package itself (which we used to do) is problematic because the package is loaded as part the R CMD check, so it then installs webppl inside itself and takes up too much space to pass check. /usr/bin is for executables, I think? Not sure what the best practice for this is.

[hawkrobe]

What do you mean by issues with "execution paths in R"?

We were trying to walk Mike through a fresh install of rwebppl, and got to a point where his machine just hung after typing webppl("flip(0.5)"). One idea about why was that this while loop never had its condition met:

  # wait for output file or error file to exist
  while (!(file.exists(output_file) ||
           (file.exists(error_file) && file.info(error_file)$size != 0))) {
    Sys.sleep(1)
  }

which might mean that it couldn't find the webppl installation to call the function and populate the output_file?

[mikabr]

Did webppl get installed successfully? We can only speculate wildly about what the actual issue is from "no output got written"...

[hawkrobe]

We were able to run a simple program from the command line, but admittedly didn't have a lot of time to investigate closely.

[mikabr]

Running webppl from the command line would use the global webppl install, which is completely separate from the rwebppl webppl install.

[hawkrobe]

Hmmm, well he didn’t have webppl installed previously, so we had to explicitly use the rwebppl install. Unless rwebppl installs it twice?

On Jun 13, 2016, at 6:14 PM, Mika Braginsky notifications@github.com<mailto:notifications@github.com> wrote:

Running webppl from the command line would use the global webppl install, which is completely separate from the rwebppl webppl install.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/mhtess/rwebppl/issues/21#issuecomment-225754331, or mute the threadhttps://github.com/notifications/unsubscribe/AFBKyNwAhFBK3mNrK8PlDmh5CTLrSGy3ks5qLgCTgaJpZM4Izcpf.

[mikabr]

Oh I see. Well it's hard to debug remotely, but it doesn't seem like the way to go is to just assume that the problem was caused by rwebppl's webppl install being in the home directory?

[hawkrobe]

This is true! But I also opened this issue because Mike said he thought it was a bit weird and out of the norm to put rwebppl's webppl install in the home directory. I don't think other R packages put stuff in the home directory, for instance. Maybe /usr/local would be the right place?

http://unix.stackexchange.com/a/73657

[mhtess]

And now I think I'm remembering @mikabr , the reason why we don't install in the user's /usr/local/lib/node_modules/ is incase the user has another version of webppl living there? That is what would happen if you did npm install -g webppl, and I seem to recall us going through that logic at some early point.

If this is the reason, then I think that's actually not a concern, because if the user has installed webppl using npm (as opposed to via github), then she will not be upset that we are reinstalling it using npm. It will just update her version.

[mhtess]

Got the following report when trying to install RWebPPL on greg's machine (R v 3.3; npm v 3.9.5; node v. 4.4.5 Mac OS 10.11.5)

installing *source* package ‘rwebppl’ ...
** R
** inst
** preparing package for lazy loading
** help
*** installing help indices
** building package indices
** testing if installed package can be loaded
npm ERR! Darwin 15.5.0
npm ERR! argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--save" "webppl"
npm ERR! node v4.4.5
npm ERR! npm  v3.9.5
npm ERR! path /Users/Greg/.npm/_git-remotes/_templates
npm ERR! code EACCES
npm ERR! errno -13
npm ERR! syscall mkdir

npm ERR! Error: EACCES: permission denied, mkdir '/Users/Greg/.npm/_git-remotes/_templates'
npm ERR!     at Error (native)
npm ERR!  { [Error: EACCES: permission denied, mkdir '/Users/Greg/.npm/_git-remotes/_templates']
npm ERR!   errno: -13,
npm ERR!   code: 'EACCES',
npm ERR!   syscall: 'mkdir',
npm ERR!   path: '/Users/Greg/.npm/_git-remotes/_templates',
npm ERR!   parent: 'webppl' }
npm ERR! 
npm ERR! Please try running this command again as root/Administrator.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/Greg/.rwebppl/npm-debug.log
* DONE (rwebppl)

[mikabr]

I'm fine with putting it in usr/local/lib, but I don't think we should override the global webppl install, that seems like potentially problematic behavior. Sidenote: doesn't webppl itself put its packages in ~/.webppl?

[mhtess]

Talking with Andreas, it seems like what we should do is check if webppl is installed using either webppl --version or which webppl, and find out where it is.

If it's not installed, the user can be told she can install it using install_webppl(). In this case, it makes sense to use npm install -g webppl. But note that npm install -g cannot be relied upon to put it in a specific directory, we still need to find out where it is using which webppl.

rwebppl should be in the R package directory. We can go to that directory and run npm link webppl to create a symlink as suggested here

Regarding packages and the install_package() function. The default behavior should be to install the package in the local project directory. There should be an option to install the WebPPL package globally. These are described in the webppl docs

Note: It is unclear whether the symlink procedure will work for Windows (or any of this for that matter). But, if we only have a few Windows users, we can figure out a manual install procedure.

[mikabr]

Why interact with the global webppl install at all? It seems unnecessarily complicated, and questionable given that we don't just install webppl, we also put in the different js runner file. We can just do the same installation process as we do now, but in usr/local/lib (or wherever we think is best practice).

[mhtess]

Thoughts from Andreas (and I)

why interact with the global webppl install?

installing a duplicate version of webppl:

1. complicates future updates
2. prevents users from easily using the version of webppl that they want to use (when it differs from that on npm)
3. just seems unnecessary

we also put in the different js runner file

In either setup, the runner file doesn't get put into the webppl directory. It’s just an external file that uses webppl as a library

[mhtess]

Also, consider the analogy to rpython (which allows the use of python from r). it doesn’t install its own version of python, as far as i know

[hawkrobe]

@mikabr: I tried a few things, but ended up going back to installing within the package itself (and sym-linking the user's global webppl installation there if we can find one). I read what you said about R CMD check at the top, but since @mhtess said we're not currently aiming to get it on CRAN, we thought it's maybe a lesser priority than making sure installation works consistently.

[mhtess]

FWIW, this did seem to solve Mike Frank's install issue (as well as Greg's)