0

EDIT: see edit in end.

I have a R package in github and I'm using devtools::install_github to install it, which also install dependency packages.

Recently this process will install httpuv as source package, but compiling it in Mac meet errors with automake (something like this). I installed automake, then there was error with clang: error: unsupported option '-fopenmp'.

The issue and the possible solutions 1 2 seemed to be quite complicated. I think the CRAN version of httpuv probably will work for me, and I don't want my users to go through so many errors and fixing compiler errors.

I'd like to just install all dependency packages from CRAN in binary. For some packages that do need the more up to date version, I have specified it in my package description with remote section.

I checked install_github, then install, then install.packages. It seemed that the default behavior for binary vs source package is

An alternative (and the current default) is "both" which means ‘use binary if available and current, otherwise try source’. The action if there are source packages which are preferred but may contain code which needs to be compiled is controlled by getOption("install.packages.compile.from.source").

My getOption("install.packages.compile.from.source") is interactive. This is actually a preferred behavior for me. However I never see the interactive prompt.

I tried to give a type = "binary" parameter in install_github, but it doesn't seem to work, maybe it's not passed to every dependency package install?

EDIT:

I found the situation is a little bit more complex:

  1. my app specified to install shiny github version via remote in description. shiny specified to install httpuv github version in remote section too. So this is actually the intended behavior.
  2. I'm not sure if there is a solution available, other than require CRAN version of shiny in my package.

EDIT 2: It's more complex than my previous findings.

  1. I removed remote section in my package description, supposedly only CRAN version is needed. However install_github still install most dependencies from github.
  2. I finally found out that I have these dependencies github version installed, so their description in my local disk have the github remote information, and install_github found this information and "upgrade" them again, even when some of them have no change.
  3. So I need to uninstall them first, only use CRAN version.

The really problem here is that if a dependency package is already new, it should not be installed. It could be a bug of devtools.

dracodoc
  • 2,603
  • 1
  • 23
  • 33
  • 2
    Why don't you just install httpuv first? – Dirk Eddelbuettel Feb 26 '18 at 19:06
  • I have httpuv CRAN version installed already, but the github version is always tried in each installation. And I cannot get the github version installed because of the compilation errors. I looked at the dependency again, found this might be intend behavior actually, see new edit in original question. – dracodoc Feb 26 '18 at 20:16
  • Maybe cheat by making the CRAN version number of httpuv 'larger' than the one at GH. But heck--there is a reason I prefer _repos_ but fighting the sillyness you are fighting now is a step down from `install.packages()` and friends which just work. – Dirk Eddelbuettel Feb 26 '18 at 20:29
  • Yes I think I need to look at drat seriously now. I also found install_github is installing some package from source again and again even I just installed them. – dracodoc Feb 26 '18 at 20:37
  • Well I am glad you reconfirmed that computers are still deterministic. – Dirk Eddelbuettel Feb 26 '18 at 20:44
  • @DirkEddelbuettel, I looked at drat. I assume if I deliver my package through drat, all the dependencies will be installed with `install.packages`. Does that means if I need a dev version of package, I need to put that release into my repo manually? – dracodoc Feb 27 '18 at 16:01
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/165910/discussion-between-dracodoc-and-dirk-eddelbuettel). – dracodoc Feb 27 '18 at 16:01
  • Yes, you'd need that dev version in a drat repo. But given that you mix and match multiple drat repos, that is no real constraint. Sorry, at work so can't chat. – Dirk Eddelbuettel Feb 27 '18 at 16:23
  • Thanks! The "chat" is just a longer form of comments thread suggested by stackoverflow, not really real time chat. – dracodoc Feb 27 '18 at 19:30
  • @DirkEddelbuettel, just want to let you know my several findings: 1. I have dependencies packages installed by install_github before, the github remote info was written in installed package description 2. thus install_github look for github repo even my package no longer specify any github remote 3. the dependency packages was installed again even they are latest, probably a devtools bug 4. I looked at drat, also found drat can be supported by shinyapps deployment which was my biggest concern. So I'll try to move to drat now. – dracodoc Mar 01 '18 at 16:08
  • @dracodic Just read your last edit. That is ... pretty bad on the part of `install_github()`. – Dirk Eddelbuettel Mar 01 '18 at 16:11

1 Answers1

2

install_github passes arguments to devtools::install, and there upgrade_dependencies= FALSE and maybe even dependencies = FALSE might be what you're after:

install_github("you/urPackage", upgrade_dependencies = FALSE)
Hugh
  • 15,521
  • 12
  • 57
  • 100
  • Yes this can solve the specific case that I have binary version installed and don't want to upgrade to source version, but this probably is not a good idea to instruct my users to always use this... – dracodoc Feb 27 '18 at 14:31
  • 1
    I realized that I can combine this method with install.packages: 1. install.packages for all my package dependencies first, then use `nstall_github` with `upgrade_dependencies = FALSE`. This should make sure all dependencies got installed/updated with binary version, and my package is still delivered through github. – dracodoc Feb 27 '18 at 15:54
  • I think I found the real problem cause. I edited my original question. – dracodoc Mar 01 '18 at 15:24