Hi, Björn,
Looks pretty similar!
Aren't the links your notebook generates transient? I think if you put them into a tool_dependencies.xml, they will fail permanently immediately after any of the package authors updates one of the relevant svn repositories?
 
AFAIK, it looks like the whole BioC/CRAN infrastructure is automated so a link that works today like http://cran.fhcrc.org/src/contrib/Rcpp_0.11.3.tar.gz will fail when Rcpp next gets updated and Rcpp_0.11.3.tar.gz is migrated to http://cran.fhcrc.org/src/contrib/00Archive/Rcpp/ with a replacement (eg) http://cran.fhcrc.org/src/contrib/Rcpp_0.11.4.tar.gz appearing in the contrib directory?

That's why my more complex script downloads all the latest archives into my local github archive repo and generates a permanent link to suit that github repo.
We definitely need an automated solution as this is a really infuriating aspect of trying to make code relying on R/BioC packages reproducible.


On Thu, Jan 8, 2015 at 11:28 PM, Björn Grüning <bjoern.gruening@gmail.com> wrote:
Hi Ross,

this is great!
Have you seen this notebook?

http://nbviewer.ipython.org/github/bgruening/notebooks/blob/master/R/extract_all_dependencies_from_an_r_package.ipynb

It tries to do the same thing. Maybe it's also worth to mention? Maybe
we can enhance it?

Thanks,
Bjoern

Am 08.01.2015 um 08:09 schrieb Ross:
> This may be helpful for anyone else struggling to get complex nested R
> package dependency installation from the tool shed sorted out. That whole
> can of worms. While we have setup_r_packages, the developer still has to
> figure out the right magical incantation and make sure the tarballs are
> available.
>
> https://wiki.galaxyproject.org/SetUpREnvironment has some notes I've
> started - contribitions welcome.
>
> It has a more or less reusable R script to generate tool_dependencies.xml
> boilerplate, assuming you set the constant libdir to your local git
> repository path where those tarballs will be downloaded from.
>
> I hope this helps someone!
>
> Could make a tool to do this if enough developers want access to it without
> the pain of managing yet another R script?
>