craigcitro / r-travis

Tools for using R with Travis (http://travis-ci.org) in lieu of a website:
https://github.com/craigcitro/r-travis/wiki
Apache License 2.0
176 stars 42 forks source link

Travis not utilizing updated packages? #166

Closed zkamvar closed 8 years ago

zkamvar commented 8 years ago

I've run into a strange problem. A package I maintain is not able to be installed on Travis because of an apparent namespace issue:

Building with: R CMD build --resave-data --compact-vignettes=gs+qpdf
$ R CMD build  .
* checking for file ‘./DESCRIPTION’ ... OK
* preparing ‘poppr’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... ERROR
Loading required package: adegenet
Loading required package: ade4

   /// adegenet 2.0.0 is loaded ////////////
   > overview: '?adegenet'
   > tutorials/doc/questions: 'adegenetWeb()' 
   > bug reports/feature resquests: adegenetIssues()

This is poppr version 2.0.2.99.230. To get started, type package?poppr
OMP parallel support: available

This version of poppr is under development.
If you find any bugs, please report them at https://github.com/grunwaldlab/poppr/issues
Loading required package: ape
Error in unloadNamespace(package) : 
  namespace 'ape' is imported by 'poppr', 'adegenet', 'pegas', 'phangorn' so cannot be unloaded
Quitting from lines 205-212 (mlg.Rmd) 
Error: processing vignette 'mlg.Rmd' failed with diagnostics:
Package 'ape' version 3.3 cannot be unloaded
Execution halted

The command "R CMD build  ." failed and exited with 1 during .

The odd thing is that this error states ape version 3.3, while the log states that version 3.4 is installed.

This check works on my machine as well as win-builder. I can't seem to figure out what the source of the error is. Is there some sort of hidden cache that is happening in travis?

craigcitro commented 8 years ago

so there's no special caching -- version 3.3 got installed as a binary dependency. when we install the dependencies for the package itself, we pick up a newer version as a source package.

IIUC, the issue here is a mix of binary dependencies and Depends. i think the binary version of adegenet ultimately loads the binary version of ape; when you call library("ape") at runtime to load the newer source package, it tries to unload the old one, but can't, and badness ensues. this would line up well with the fact that this only happens on travis, which (I'm guessing) is the only place you're doing binary package installs?

one easy workaround is to just avoid picking up adegenet and friends as binary packages, and install from source. it takes a bit longer, but it works. i'm happy to just send a PR if that works for you.

i think getting a newer version of adegenet and ape as binary packages would be another fix.

zkamvar commented 8 years ago

Thanks for looking into this. I tried switching to binary packages a while back because my builds were taking northwards of 30 minutes, so I can live with 11. A PR definitely works for me. Thank you for checking this out!