On Fri, Oct 28, 2016 at 9:38 AM, Dima Pasechnik <dimp...@gmail.com> 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. -- 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+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. -- 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.
