Hi ( I hope this is the right place to post this; if not, please lmk!),
I am trying to deploy a Shiny app to RStudio Connect. Things go swimmingly until packrat tries to install a library that is required from my private Github repository and ends with the following error messages:
2017/10/14 13:47:29.838948025 FAILED
2017/10/14 13:47:29.849146344 Error in getSourceForPkgRecord(pkgRecord, srcDir(project), > availablePkgs, : Failed to download package from URL:
2017/10/14 13:47:29.849177811 - GITHUBAPI/repos/USERNAME/PACKAGENAME/tarball/HASH'
It points me to docs on private packages which did not really clarify the following three things for me. I'd appreciate any help with those!
I understand the docs to say that there is no way to get RStudio connect to directly upload the relevant files from my local drive as e.g. I think I am able to do on shinyapps.io. Is that true?
I understand the docs to say that there is no way for RStudio connect to download files from a private Github repository. That is, even if the file listed in the error messages was online, as long as it was in a private repository, I can't just add a token or similar to enable the system to access it?
The docs offer a few solutions, some of which (e.g. setting up a private repo) seem like an obvious overkill. Is there a best practice approach to get your own local library up on there? I feel it is common to clean up your main script by writing a library. How do you guys usually handle this?
(Locally, I just access the library by installing it from Github with a Token).
Thanks do much for your help!
For our Rstudio Connect server, we prefer to use a private repository. I find it easier than the other solution (installing package directly in the server, with git hash tracibility and all)
When I make a release from a private repo, I built it and add it into the specific package cran-like repo accessible from our RStudio connect server. Works fine and not so difficult to implement. Moreover, It could easily be automated using continues integration to publish in the repo when we make a new release.
I agree with @cderv - the private-repository solution works well for me. It is not much of a hassle to set up, but it has been well worth the effort.
I use Dirk Eddelbuettel's drat package to manage my private CRAN-like repository, let's call it MYRAN. My company uses Github Enterprise (GHE), so I can serve the CRAN-like repository using GHE's pages service.
On the computers that will use MYRAN, I modify .Rprofile (or Rprofile.site, as needed):
I confirm that drat is useful. In my case, I don't host may MYRAN repo on github but on internal network. I found that some functions of miniCRAN and packrat can be of help to.
Glad to know others have similar solutions! Thanks for sharing!
In recent versions of RStudio Connect (> 1.5.4) there is also the option to manually install a package on the Connect server and whitelist the package (meaning that Connect will ignore the packages entirely). This should be a last resort - you miss out on all the package management goodness - but is an additional option.
Hey @slopp, what is the recommended method for doing this with on-prem GitHub/Lab? We have a number of repositories that are "public" within our intranet. install_git(<internal repo url>) works without issues from both my desktop as well as the rstudio-connect host, but unfortunately deploying to rstudio-connect complains about source packages and search CRAN, then failing. devtools::install_git does seem to add some "source location" metadata to the DESCRIPTION of the installed package, perhaps that can be parsed?
I forked the drat package and created a gh-pages branch, put my package out there and pushed it. When I navigate to the https://pages.github.my-company.com/path/drat/ I only see "drat" on the page and no files. Do I need to merge my dh-pages brach with the main drat?
When I did this for my company, I didn't fork the drat package - instead I used install.package("drat"), then used its functions to create a drat-project repository on my local computer. That drat-project repository then gets pushed to the company's GitHub Enterprise (GHE) where it is served using its "pages".
The drat vignette suggests that you do all of your work in the gh-pages branch of your drat-project repository. I suggest using the main branch, then explicitly turning on pages for the main branch at GHE.
Since my original post, I have written up a more-detailed procedure - I don't know if this may help shake the answer loose.