On Friday, October 28, 2016 at 3:03:26 PM UTC, William wrote: > > Hi, > > Regarding the openssl dependency issue, the standard way people > justify getting around it is the "system library exemption", which > allows for GPL'd programs to link in system libraries that are not > GPL'd (otherwise, things like GPL software on MS Windows would be > impossible!). Some links here: > > > http://opensource.stackexchange.com/questions/2233/gpl-v3-with-openssl-exception > > > As the person who chose to add R to Sage in the first place, my > instinct on this is that we should **completely and totally remove R > from Sage**. Why? > > - Our pexpect based interface to R sucks. It was mostly written by > Mike Hansen and me, so I take the blame. In SageMathCloud Sage > worksheets > we just switched to making the %r mode be implemented using Jupyter's > R kernel, which is way more robust. > > - It's easy enough to install R in other ways outside of Sage. > I've heard of a lot of people installing Sage in order to install X > (where X is say Pari or Singular or even Cython at one point); I've > *never* heard of anybody installing Sage in order to get R. > > - The main technical reason for installing R into Sage, as opposed > to just finding a system-wide R install, is to ensure that rpy2 -- the > C-level bindings to R -- actually work.
What would prevent it from working if R is not included in Sage? rpy2 is pip-installable. Doing "pip install rpy2" on my system python (3.5) gave me a running version of rpy2 (talking to system-wide R 3.3.1). I didn't try with python2, but they say it's supported this way too. Just make rpy2 an optional Sage package... Dima > However, in retrospect, I > don't think rpy2 is really that great. > > - Python stats have come a *LONG* way in the last 10 years, with > libraries like Pandas. Why use rpy2 when you can much more > effectively use pandas and statsmodels and so on. > > In my opinion, it would be way, way better to completely remove R from > Sage and instead do the following: > > 1. Include the R jupyter kernel config files. > > 2. Includes the modern Python stats libraries pandas and > statsmodels in Sage. > > Our time would be much better spent supporting 2 than 1. It's > ridiculous that we spend no effort on pandas/statsmodels, and all this > effort on R. That was a strategy that made sense 10 years ago, but > not today. > > For example, I recall that there are some issues involving pandas + > statsmodels + the sage preparser. We could put effort into > addressing those, like Robert Bradshaw did with numpy (which used to > be very unhappy with Sage integers, reals, etc.). Fixing this stuff > probably wouldn't be hard, and would make Sage a better environment > for stats. There may be similar remarks around machine learning, > where Python has really come into its own recently (e.g., see > tensorflow). > > Anyway, just my two cents. But if anybody was out there wanting to > propose something similar, but worried that the person who included R > in Sage in the first place would be really annoyed -- fear not. > > -- William > > On Fri, Oct 28, 2016 at 6:39 AM, Emmanuel Charpentier > <emanuel.c...@gmail.com <javascript:>> wrote: > > My thoughts so far : > > > > I : Is there really a problem ? > > ===================== > > > > What all the brouhaha around libcurl boils down to is that there *might* > be > > a (pseudo)-legal difficulty in shipping a libcurl liibrary requiring > OpenSSL > > and a GPL-licensed piece of software *in the same package*. This might > be a > > part of the reasons for the R core team to have thrown the towel on this > > (but probably only patr of the reason : they alo threw the towel on xz > an > > pcre, which do not give the same headache). > > > > However, this does not seem to be a problem per se : Debian (one of the > most > > nitpicking distros in terms of licensing) happily ships libraries and > > utilities (such as cups, for starter) linked with openssl-linked > libcurl. I > > think that it would be interesting to ask them how they reconcile the > > (inconsistent) wordings of the licenses involved. > > > > According to their answer, we might have an easy way out : hide behind > the > > same legal curtain as Debian (it remains to see what it is...), package > > libcurl (essentially done) and silently ship it with Sage (it remains to > > check if other libraries are not more or less silently involved in the > > support of https: in libcurl, in which case we might have to use them > also). > > This is option : > > > > a) Do nothing : > > -------------------- > > > > II ? If there is really a problem, what can we do ? > > =================================== > > > > We might also bite the bullet, modify our licensing terms to add the > > advertising clause required by openssl's license and ship openly > libcurl. > > Tha requires, it seems, explicit permission of all the people havng > > contributed to Sage, which might prove a difficult (impossble ?) task. > That > > gives us option : > > > > b) Acknowledge libcurl > > --------------------------------- > > > > We can also emulate the R core team, throw the towel and simply add (an > > https-capable) libcurl to our initial requirements in README.md, > possibly > > other places), leaving the user with the responsibility of installing > it. > > This is option : > > > > c) Throw the towel > > --------------------------- > > > > Another possibility in the same vein is to throw the whole linen cabinet > : > > instead of placing on user's shoulders the responsibility of finding > > libcurl, we might leave it the responsibility of installing R. This is > made > > possible by the fact that R is now largely stable, with well-documented > > interfaces and few changes, therefore standardizable. A review of *all* > the > > points of exchange between R and other parts of Sage would be necessary > to > > check what is to be supported. As far as I know, R is sparsely used in > "the > > rest of Sage. This is option : > > > > d) Excise R kernel > > --------------------------- > > > > At that point, one might wonder if R should remain a standard part of > Sage. > > Dropping the requirement for T and making R interfaces an optional part > of > > Sage might also be a solution. But this is possible if and only if the > code > > review necessary to Sage excision shows no use of R's capabilities in > other > > standard part of Sage. This is option : > > > > e) Excise R interfaces > > -------------------------------- > > > > I think that we can forget about creating a network-deprived R : the > > resulting loss of functionality is so massive that it would become > almost > > useless (to people having a use for R, that is...). I have to add that I > > would fight such a "solution"... > > > > III : Pros and contras > > ------------------------------ > > > > "Throw the towel" is the laziest option : a few lines of not > hard-to-write > > documentation in a few (harder-to-find ?) places. It buys us nothing in > > terms of functionality. And leaves us with the responsibility of > updating R > > (a not-so-insignificant task) and large sources, libraries and > executables. > > > > "Do nothing" is (almost but not quite) as lazy: porting libcurl is > > essentially done ; it remains to check if other libraries are required > to > > build an https:-capable libcurl. No other benefits. > > > > "Acknowledge libcurl" seems almost infeasible, due to the necessity to > hunt > > all the past and present Sage contributors. It would be otherwise the > > cleanest solution in the eyes of legal-oriented people. > > > > "Excise R kernel" needs a serious bit of work. But it would have its > points > > : document all the uses of R from other parts of Sage, forcing the > > documentation of these uses, etc... It would also lighten the > maintenance of > > Sage. However, we would be exposed to brutal loss of functionality > if/when R > > changes without warning. Furthermore, paranoid users (such as me :-) > would > > not have to maintain "system" and "Sage" installations of R (not a small > > task with litteraly thousands of R packages available...). > > > > "Excise R interfaces" is probably easy to do (modulo the code review > > necessary to excision) ; in my not so humble opinion, it would be a > serious > > loss of interest for me and, more generally, a catastrophic mistake in > > communication : R has been part of Sage since version 3.0 (2008) (if > > Wikipedia is to be believed), and it would be the first ever > *intentional* > > loss of functionality of Sage. Furthermore, I am a bit skeptic about R > > interfaces maintenance if they ever becom an optional part of Sage : > even > > the (Sage) notebook, which is pretty central, has attracted cruft to > the > > point of becoming unmaintainable... > > > > My short-sighted laziness would go to "Throw the towel" ; my long-term > > laziness would choose "Excise R kernel" (it could be the former now, the > > latter afterwards). However, notwithstanding its drawbacks, "do nothing" > is > > almost done. > > > > What do you think ? > > > > -- > > Emmanuel Charpentier > > > > -- > > 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 sage-devel+...@googlegroups.com <javascript:>. > > To post to this group, send email to sage-...@googlegroups.com > <javascript:>. > > Visit this group at https://groups.google.com/group/sage-devel. > > For more options, visit https://groups.google.com/d/optout. > > > > -- > William (http://wstein.org) > -- 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 sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
