On Wed, Jun 5, 2013 at 2:18 PM, John Chilton <chilton@msi.umn.edu> wrote:
Three quick comments on this thread:
- A real short-coming of my colleague JJ is that he doesn't possess a tenth the ego that I do, so he doesn't care, but I think it is important he gets credit. He did 85% of the work, and the harder 85% at that, so they should be called the JJ changes.
- It is possible to get rpy working with newer versions of R (at least 3.0.0) because CloudBioLinux is configured this way and it seems to work for me. (Not that there aren't other problems - https://github.com/chapmanb/cloudbiolinux/commit/302072341696390dc1cf3ae1dd8...). CloudBioLinux is configured to get its rpy packages here http://watson.nci.nih.gov/cran_mirror/bin/linux/ubuntu/{precise,quantal} which has versions compatible with R 3.0.0.
- Finally, an idea - "Death to RPY - The BoF". Everyone with a stake in this meets with laptops at the Galaxy conference together and we divvy up the remaining tools to convert (hopefully one tool per person). Every person is also assigned two of the existing converted tools to retest and clean up. As they are completed they are given to a core Galaxy developer (Nate, Dannon, Daniel, any volunteers?) to collect, re-retest, and okay. The changes are then committed all together at the end and the next Galaxy release contains no dependencies on rpy.
These tools are not updated frequently, so the advantage of these all being upgraded in one commit before being shipped off to the tool shed is that an institution that is really stuck on rpy1 for whatever reason can just undo that single commit and keep going with the old tools indefinitely.
If anybody with commit access signs on I will be happy create a BoF page and attend this.
Thanks, -John
If you all can pull that off in Oslo, great. Otherwise a piecewise conversion seems a sensible plan B, where both rpy (v1) and rpy2 are installed and things are updated on a tool by tool basis. The BoF group might also have some collective wisdom on how to deal with the question of multiple versions of R/BioConductor given this is important for reproducibility of many more complex and rapidly developed R tools. Peter