as pointed out by John a real r_environment would be nice, to facilitate the installation of R packages and make that procedure reproducible. Here is my solution and drive the discussion further. With the following patch the following should be possible:
If we can merge that system at some point, I will start writing a best-practise guide for R packaging.
@peterjc and other requested that and I think its a good idea. If you review that patch, please take John's ruby-environment pull request also into account:
and hope to migrate it at some point to this proposed system here.
As you see we need a mirror for tarballs, maybe it is now the right time to kick that idea also further and create a mirror system for bioinformatic tarballs.
What do you mean for nice installation routines for python? Is there another new action type I've missed?
The R tarballs requirement does seem part of a larger need, perhaps the Galaxy Tool Shed should cache those? It wouldn't really need revision control... something to discuss on the mailing lists?
There is a "setup_virtualenv" action type for python, afaik.
Yes, the caching idea needs to be discussed. I need to write several mails, hopefully today. James raised that idea a few days ago on the mailinglist.
Fantastic! Keep it up :)
Can the 'set_environment' occur automatically when using setup_r_environment? Will that expression be different in different circumstances?
Also, I think I would prefer package to r_package for the name of the inner tag, we are already in an R action environment so the r_ prefix seems redundant. Just a personal preference though, obviously feel free to ignore :).
Another thing that would be cool is to allow the actual R packages to be placed right in the repository, but maybe tool_dependency_definition's are not going to allow this right? Regardless, its something that could always be added later.
Changed 'r_package' to 'package'.
I was not sure about the 'set_environment' thing and wanted to discuss that at first with @greg or @inithello.
We definitely need to discuss, where we want to store the tarballs.
Added the R_LIBS env variable automatically. I also added a ToDo, that we should refactor that part at some point.
Thanks @jmchilton for pointing that out!
I was also wondering about bundling the dependency tar-balls into the Tool Shed repository, but as you say John, it would break the current rule that a package only has the single tool_dependencies.xml file (and it could result in a lot of duplicated tarballs too).
You guys are so fast ... great! I will try to address all issues and start discussion on the mailing list.