I would be in favor of keeping R, it is basically the only thing that we have for statistics. This is different from Octave, say---anything that you could do with Octave you can basically do with Sage, but there is very little that we currently can do to replace R functionality. Having said that, there is a serious lack of statistics in Sage.
Also, having an optional R spkg will just mean less testing exposure. No testing on the buildbot or by the general Sage user community -> won't work. IMHO the real problem is * slow review of no-brainer updates of dependencies, * an arcane packaging procedure that makes it difficult to see what is being done, and * LD_LIBRARY_PATH hurting us all the time. At least the last two points are just technical issues to solve. With git the actual changes will be just as easy to see and review as sage library changes. And we really need to get rid of the LD_LIBRARY_PATH hack. As for the first, we IMHO shouldn't pretend that we are reviewing trivial third-party upgrades. A version bump just has to build on all supportend platforms and pass the tests, thats much much more important than some bikeshedding over what kind of conditionals are more beautiful / less ugly in bash. On Thursday, November 21, 2013 7:45:41 AM UTC-5, jason wrote: > > > tl;dr: I propose that we remove R from our standard packages and > encourage people to install it separately. > > Long version: What in Sage uses R to provide Sage functionality? Or do > we include the R package just because it's a cool open-source package > that lots of people use? If so, why do we not include octave---it's > also a cool open-source package that lots of people use. > > I tried searching the source for instances of rpy---which would indicate > we were using R through the rpy or rpy2 python module, and none of these > references are actually using R.: > > % grep -rl rpy > interfaces/ecm.py > rings/integer.c > rings/integer.pyx > rings/real_double.c > rings/real_double.pyx > rings/real_mpfr.c > rings/real_mpfr.pyx > stats/test.py > > The current work on R in Sage seems to be happening here: > http://trac.sagemath.org/ticket/14706. On that post, it is summarized > that: > > a) Having an up-to-date R is a sine qua non to get answers from R Core. > > b) R in Sage is rarely up to date (more talented Sage developers work on > more important issues). > > c) Therefore, R-in-Sage users have trouble communicating with R Core > > d) I am able to create "drop-in replacements" of the R spkg, thus giving > R-in-Sage users an up-to-date R, thus allowing them to get answers from > R Core... > > e) Since this is routine work that few people seem to tackle, and since > it is in my limited ability range, I'll try to do it after R upstream > upgrades. > > That ticket notes a bunch of work, mainly (it seems) dealing with > problems compiling R in Sage's environment, but ending in positive > review now with a current version of R. So soon (in 5.13) we'll once > again have an up-to-date R. However, upstream R is a very active > project that has frequent releases that build on major platforms (more > platforms than we build on, like Windows). I'm wondering---would the > people working on that ticket prefer to work on other things (if we > interfaced nicely with a system R), or do they truly want R installed as > part of Sage? > > I propose that we remove R from the standard packages, and instead > encourage people to install R separately. I think we should keep the > rpy2 python module in the standard packages to be able to interface > easily with an already-installed R. > > Votes? > > Thanks, > > Jason > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
