Closed zkamvar closed 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.
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!
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:
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?