On Friday, October 28, 2016 at 5:24:35 PM UTC, William wrote: > > On Fri, Oct 28, 2016 at 9:38 AM, Dima Pasechnik <dim...@gmail.com > <javascript:>> wrote: > > > > > > 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? > > Since you ask, some of the things I can immediately think of: > > 1. R isn't installed systemwide (obvious) > > 2. The version of R that is installed is very old or too new compared > to the version of Sage and rpy2 that are installed. > > 3. The version of R that the user installed doesn't provide a shared > object library or dynamic link library (maybe on OS X or Windows?) > > 4. The user installed R in some local location, and there are shared > object libraries there, but Sage's Python knows nothing about this > copy of R or its libraries, so rpy2 won't build. > > That said, I'm also for rpy2 being optional and pip installable, as > you propose. Many of the above problems are best addressed by > improving rpy2 and pip, and maybe that's already happened. >
I talked to R people here at GSoC summit, and they say it should not be a problem to have rpy2 install correctly on any platform they support (the libraries rpy2 needs are always bundled, and the non-standard location of R is supported too.) > > -- William > > > 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> 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. > >> > To post to this group, send email to sage-...@googlegroups.com. > >> > 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+...@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.
