Closed eddelbuettel closed 10 years ago
Okay, I noodled with this over in my fork of r-travis, using the small rhiredis package a as test.
I added two new shell functions: one for explicit Debian/Ubuntu packages (here: libhiredis-dev) and one for explicit R packahes (here: Rcpp) as devtools failed to find needed packages from the DESCRIPTION. With some elbow grease I got it all to build but it needs some more spit and polish.
Wouldn't this (as well as GitHub packages) better be configured through environment variables or a separate configuration file?
I don't follow.
.travis.yml invokes a shell script. We list the needed Debian/Ubuntu packages (which are not known to R, and not parseable from DESCRIPTION) explicitly. This now works. The other issue was trying to work out required R package via devtools but that failed. I don't use devtools so someone else will need to debug that part. So I took a short cut and added another entry point to explicitly add CRAN packages. That fulfilled my needs, and concluded the tests.
There is no need for env.vars or a new file. It all gets tickled from .travis.yml. We "merely" need to get the code right.
.travis.yml
can configure environment variables, see my implementation: https://github.com/krlmlr/R-travis. Also, it would be possible that this shell script reads a (hidden) configuration file for all sorts of things such as GitHub and/or Ubuntu packages.
Actually, I would favor a configuration file.
Advantages of a config file:
.travis.yml
can be left unchangedI am no fan of environment variable; here it is just a matter of passing tokens for packages to add. Your script does one thing right: no sudo in front of R, but you could make it even easier by just setting write permissions to /usr/local/lib/R/site-library --- rather than creating a lib below $HOME. Anyway...
But can you please take the discussion elsewhere? This has nothing to do with my quick hack of Craig;s script.
Also, to me .travis.yml is a config file for the given R project. No need to clutter each repo with yet another file.
this was already done in your other patch, @eddelbuettel -- but i'm going to add a test here, just so i don't quietly break the feature without noticing.
Can we add a hook to supply 'foo bar giz' so that 'sudo apt-get install foo bar giz' can be executed? My (trivial) test case is my tiny rhiredis package; it needs the hiredis C library from Debian/Ubuntu in order to build.