[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Emmanuel Charpentier]

Dear Jean-Pierre,

Le mercredi 2 novembre 2016 11:40:30 UTC+1, Jean-Pierre Flori a écrit :
>
> I would say we even have a shorter-time solution: close the tickets for 
> including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking)
>

?? What do you mean ?
 

> and updating R (modulo adding a 6-line patch to not check for https 
> support,
>

I'm not really comfortable with that, but, for now, it doesn't totally 
cripple R (some repositories are still http-reachable). Nevertheless, we 
still have to depend on libcurl but with no version check.
 

> note that most of the time https will be supported anyway).
>

Okay. But that still implies accepting xz an pcre either as Sage 
dependencies or  as standard packages.

OTOH, depending on R and R library automatically ensures that the run-time 
dependencies are present...

Which ?

--
Emmanuel Charpentier


>
> On Wednesday, November 2, 2016 at 11:19:52 AM UTC+1, Emmanuel Charpentier 
> wrote:
>>
>> So far, the only plan I can propose which is consistent with the various 
>> points that have been stated  is : 
>>
>> I) short-term workaround : add a dependance for Sage, by :
>> a) depending on libcurl and its development files, or
>> b) depending on a systemwide R + its development files
>> II) solve current issues with the pexpexct interface (e. g. graphs in 
>> Jupyter...) and its documentation (e. g. use of RElement to retrieve an R 
>> object).
>>
>> This solves the immediate problem at hand (which is urgent : more and 
>> more R packages won't install on R 3.2.x). But since some have pointed out 
>> the inefficiencies of the current R interface and its documentation, we 
>> could :
>>
>> III) Build some steamlined interface ("newR") to R (via rpy2 ? via 
>> IRkernel ?). Test it
>> IV) Based on newR, build a reasonable wrapper emulating 
>> feature-for-feature the current pexpect interface. Test it.
>> V) replace the pexpect interface by the wrapper.
>>
>> This is not urgent, and can be discussed further.
>>
>> Now, for Ia vs Ib :
>>
>>- Both require modifying the installation documentation and the main 
>>configure file. These do not seem to be large modifications (I just need 
>> to 
>>learn a modicum of autotools in order to do this correctly).
>>- Both allow the current pexpect to remain a standard part of Sage.
>>
>> Ib seems to have two slight advantages on Ia :
>>
>>- R and its development files seem to be well-packaged on the few 
>>(Linux) distributions I have checked, as well as Cygwin, and probably are 
>>elsewhere (other GNU/Linuxes, assorted Unices). The Macintosh case, as 
>>usual, bears a large question mark...
>>- Paradoxically, it is probably easier for an end-user to check this 
>>requirement than to check the suitability of his libcurl...
>>- Ib does not require xz and pcre to become standard packages.
>>
>> Could we have a vote on the I-II block (which *is* urgent), and on the Ia 
>> vs Ib alternative ?
>>
>> HTH,
>>
>> --
>> Emmanuel Charpentier
>>
>> Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit :
>>>
>>> Hi all,
>>>
>>> The latest R versions depends on libcurl and actually more than that: on 
>>> a libcurl with https support.
>>> So we might want to build our own libcurl with https support (see 
>>> #21767) but we then need an SSL/TLS implementation which Sage curretnly 
>>> provides only optionally through openSSL because of license issues so we 
>>> can:
>>> [1] either make R depend on libcurl depend on openssl and they all 
>>> become optional,
>>> [2] or make R depend on libcurl and make them standard and add an 
>>> SSL/TLS implementation and its development headers a prereq,
>>> [3] or make libcurl with https support (and development headers) a 
>>> prereq, which basically means adding an SSL/TLS implementation as a prereq 
>>> as well,
>>> [4] or make R a prereq,
>>> [5] or drop R support,
>>> [6] or patch R not to use curl,
>>> [7] or patch R to use curl but without https support,
>>> [8] or wait until the end of times,
>>> [9] or a mix of all of this,
>>> [10] or do something else.
>>>
>>> What do you think?
>>>
>>> Best,
>>> JPF
>>>
>>

-- 
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.

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

I would say we even have a shorter-time solution: close the tickets for 
including curl (modulo adding a SAGE_FAT_BINARY mode to avoid overlinking) 
and updating R (modulo adding a 6-line patch to not check for https 
support, note that most of the time https will be supported anyway).


On Wednesday, November 2, 2016 at 11:19:52 AM UTC+1, Emmanuel Charpentier 
wrote:
>
> So far, the only plan I can propose which is consistent with the various 
> points that have been stated  is : 
>
> I) short-term workaround : add a dependance for Sage, by :
> a) depending on libcurl and its development files, or
> b) depending on a systemwide R + its development files
> II) solve current issues with the pexpexct interface (e. g. graphs in 
> Jupyter...) and its documentation (e. g. use of RElement to retrieve an R 
> object).
>
> This solves the immediate problem at hand (which is urgent : more and more 
> R packages won't install on R 3.2.x). But since some have pointed out the 
> inefficiencies of the current R interface and its documentation, we could :
>
> III) Build some steamlined interface ("newR") to R (via rpy2 ? via 
> IRkernel ?). Test it
> IV) Based on newR, build a reasonable wrapper emulating 
> feature-for-feature the current pexpect interface. Test it.
> V) replace the pexpect interface by the wrapper.
>
> This is not urgent, and can be discussed further.
>
> Now, for Ia vs Ib :
>
>- Both require modifying the installation documentation and the main 
>configure file. These do not seem to be large modifications (I just need 
> to 
>learn a modicum of autotools in order to do this correctly).
>- Both allow the current pexpect to remain a standard part of Sage.
>
> Ib seems to have two slight advantages on Ia :
>
>- R and its development files seem to be well-packaged on the few 
>(Linux) distributions I have checked, as well as Cygwin, and probably are 
>elsewhere (other GNU/Linuxes, assorted Unices). The Macintosh case, as 
>usual, bears a large question mark...
>- Paradoxically, it is probably easier for an end-user to check this 
>requirement than to check the suitability of his libcurl...
>- Ib does not require xz and pcre to become standard packages.
>
> Could we have a vote on the I-II block (which *is* urgent), and on the Ia 
> vs Ib alternative ?
>
> HTH,
>
> --
> Emmanuel Charpentier
>
> Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit :
>>
>> Hi all,
>>
>> The latest R versions depends on libcurl and actually more than that: on 
>> a libcurl with https support.
>> So we might want to build our own libcurl with https support (see #21767) 
>> but we then need an SSL/TLS implementation which Sage curretnly provides 
>> only optionally through openSSL because of license issues so we can:
>> [1] either make R depend on libcurl depend on openssl and they all become 
>> optional,
>> [2] or make R depend on libcurl and make them standard and add an SSL/TLS 
>> implementation and its development headers a prereq,
>> [3] or make libcurl with https support (and development headers) a 
>> prereq, which basically means adding an SSL/TLS implementation as a prereq 
>> as well,
>> [4] or make R a prereq,
>> [5] or drop R support,
>> [6] or patch R not to use curl,
>> [7] or patch R to use curl but without https support,
>> [8] or wait until the end of times,
>> [9] or a mix of all of this,
>> [10] or do something else.
>>
>> What do you think?
>>
>> Best,
>> JPF
>>
>

-- 
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.

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Emmanuel Charpentier]

So far, the only plan I can propose which is consistent with the various 
points that have been stated  is : 

I) short-term workaround : add a dependance for Sage, by :
a) depending on libcurl and its development files, or
b) depending on a systemwide R + its development files
II) solve current issues with the pexpexct interface (e. g. graphs in 
Jupyter...) and its documentation (e. g. use of RElement to retrieve an R 
object).

This solves the immediate problem at hand (which is urgent : more and more 
R packages won't install on R 3.2.x). But since some have pointed out the 
inefficiencies of the current R interface and its documentation, we could :

III) Build some steamlined interface ("newR") to R (via rpy2 ? via IRkernel 
?). Test it
IV) Based on newR, build a reasonable wrapper emulating feature-for-feature 
the current pexpect interface. Test it.
V) replace the pexpect interface by the wrapper.

This is not urgent, and can be discussed further.

Now, for Ia vs Ib :

   - Both require modifying the installation documentation and the main 
   configure file. These do not seem to be large modifications (I just need to 
   learn a modicum of autotools in order to do this correctly).
   - Both allow the current pexpect to remain a standard part of Sage.

Ib seems to have two slight advantages on Ia :

   - R and its development files seem to be well-packaged on the few 
   (Linux) distributions I have checked, as well as Cygwin, and probably are 
   elsewhere (other GNU/Linuxes, assorted Unices). The Macintosh case, as 
   usual, bears a large question mark...
   - Paradoxically, it is probably easier for an end-user to check this 
   requirement than to check the suitability of his libcurl...
   - Ib does not require xz and pcre to become standard packages.
   
Could we have a vote on the I-II block (which *is* urgent), and on the Ia 
vs Ib alternative ?

HTH,

--
Emmanuel Charpentier

Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit :
>
> Hi all,
>
> The latest R versions depends on libcurl and actually more than that: on a 
> libcurl with https support.
> So we might want to build our own libcurl with https support (see #21767) 
> but we then need an SSL/TLS implementation which Sage curretnly provides 
> only optionally through openSSL because of license issues so we can:
> [1] either make R depend on libcurl depend on openssl and they all become 
> optional,
> [2] or make R depend on libcurl and make them standard and add an SSL/TLS 
> implementation and its development headers a prereq,
> [3] or make libcurl with https support (and development headers) a prereq, 
> which basically means adding an SSL/TLS implementation as a prereq as well,
> [4] or make R a prereq,
> [5] or drop R support,
> [6] or patch R not to use curl,
> [7] or patch R to use curl but without https support,
> [8] or wait until the end of times,
> [9] or a mix of all of this,
> [10] or do something else.
>
> What do you think?
>
> Best,
> JPF
>

-- 
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.

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Emmanuel Charpentier]

Le mardi 1 novembre 2016 15:03:19 UTC+1, Samuel Lelievre a écrit :
>
>
>
> Fri 2016-10-28 17:03:26 UTC+2, William:
>  
>
>>- 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).
>>
>  
> These issues with Sage integers were recently illustrated
> by this Ask Sage question:
>
>
> https://ask.sagemath.org/question/35270/sage-vs-python-integers-and-floats-in-pandas-matplotlib-etc/
>
> If anyone knows how to fix that, it would be very appreciated.
>

Auto-casting ? That should be solved on Panda's side...

--
Emmanuel Charpentietr 

-- 
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.

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Samuel Lelievre]

Fri 2016-10-28 17:03:26 UTC+2, William:
 

>- 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).
>
 
These issues with Sage integers were recently illustrated
by this Ask Sage question:

https://ask.sagemath.org/question/35270/sage-vs-python-integers-and-floats-in-pandas-matplotlib-etc/

If anyone knows how to fix that, it would be very appreciated.

-- 
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.

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Emmanuel Charpentier]

Dear William,

Sorry to have sounded frightened by *you* : I'm frightened by the amount of 
*my* ignorance...

Since it seems that I'm (almost) alone among Sage users to be interested by 
the development of an interface to R, I'm exploring the options. And I'm 
trying to understand things I was used to *use* (as you use your car 
without thinking about the thousands of engeenering problems that had to be 
solved to make it "just run"). So I try to list all the possible solutions 
and ranking them also by a very personal criterion : the amount of knew 
knowledge I will need to use them... Your description of Jupyter kernels 
makes me put it at the extremity of my list...

You do not have to convince me that pexpect is a poor way to do it : I'm 
convinced : the data interchange involves a serious amount of playing fast 
and loose with Python and R dumps. Not quite steamlined...

Sincerely,

--
Emmanuel Charpentier

Le jeudi 27 octobre 2016 10:03:03 UTC+2, Jean-Pierre Flori a écrit :
>
> Hi all,
>
> The latest R versions depends on libcurl and actually more than that: on a 
> libcurl with https support.
> So we might want to build our own libcurl with https support (see #21767) 
> but we then need an SSL/TLS implementation which Sage curretnly provides 
> only optionally through openSSL because of license issues so we can:
> [1] either make R depend on libcurl depend on openssl and they all become 
> optional,
> [2] or make R depend on libcurl and make them standard and add an SSL/TLS 
> implementation and its development headers a prereq,
> [3] or make libcurl with https support (and development headers) a prereq, 
> which basically means adding an SSL/TLS implementation as a prereq as well,
> [4] or make R a prereq,
> [5] or drop R support,
> [6] or patch R not to use curl,
> [7] or patch R to use curl but without https support,
> [8] or wait until the end of times,
> [9] or a mix of all of this,
> [10] or do something else.
>
> What do you think?
>
> Best,
> JPF
>

-- 
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.

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[William Stein]

On Sun, Oct 30, 2016 at 12:09 PM, Emmanuel Charpentier
 wrote:
> Dear William,
>
> thanks for this advice, which I'll consider seriously, notwithstanding its
> total opacity to me at the moment
>
> I just checked that the r interface in SMC is indeed different from what
> exists in sage "standalone". It is also a bit difficult to understand, due
> to present lack of documentation. Cut-n'paste from a sagews :
>
> help("r")
> ︡983aebe0-3f6e-46ff-9d40-ce8e153480d2︡{"stdout":"no Python documentation
> found for 'r'\n\n"}︡{"done":true}︡
>
> But the behavior of R in % cells is crystal-clear. The first difficulty I
> have is to understand how to exchange data (or other structures) between R
> and Sage (which is the *whole* point of the exercise...).
>
> Do you think that this R interface, specific to Sagemath Cloud, could be
> ported to Sage ? And do you think that t would involve R-version specific
> code ?

I don't think this question really makes any sense.  What you have to
do is simply learn Jupyter... then rethink the question.   Except
that's harder than it should be...!  I just posted this to
https://gitter.im/jupyter/jupyter:  "Hi, I just spent a shockingly
large amount of time searching and googling for basically an overview
of what a Jupyter kernel is and how to write one. There's some old
deprecated docs about this, which all have big pointers to newer docs.
I can't find any new docs that simply explain what a Jupyter kernel is
and how to write one. I'm trying to convince other Sage developers to
use Jupyter kernels instead of the pexpect interfaces I wrote for Sage
-- at least for R mode -- and it's impossible to convince them if I
can't even point to the docs. So help... For example, going here, I
would expect under "Kernels" the docs I want, but I can't find
anything."

>
> Another potential stumbling point it that the main part of the interface
> (the IRkernel package), has not (het) been accepted by CRAN, rendering its
> future ability questionable.
>
> I plan to look also at what is offered by the Rpy2 interface It would take a
> bit of work to emulate the behavior of the pexpect nterface, but that might
> offer a good interim solution (at this time, I have *no* idea about what the
> IRkernel and its companion libraries are supposed to do).
>
> Last recourse : the R library itself. Again, I don't know (yet) what it
> offers.
>
> Again, thank you for your (a bit frightening...) advice,

Sorry for being scary.   It's just advice.  Feel free to ignore, of course.

> --
> Emmanuel Charpentier
>
> Le dimanche 30 octobre 2016 17:10:31 UTC+1, William a écrit :
>>
>> On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier
>>  wrote:
>> > OK. It seems that a clear consensus exists for the excision of R
>> > _proprio
>> > dictu_ from Sage.
>> >
>> > If we break it, can we at least keep the (Sage's) pieces ? An optional
>> > package offering the current R interface(s) depending  on a
>> > systemwide(at
>> > least user-reachable) version of R and the R library might offer the
>> > functionality without entailing the (not so trivial) work of maintaining
>> > our
>> > own R port.
>> >
>> > Do you have an idea of the amount of work involved ? And how to, do it ?
>> > The
>> > rpy2 part is probably easy, but I expect surprises on the pexpec(t)
>> > front
>> > (at least if we want to keep compatibility with existing code using
>> > current
>> > R interface facilities...).  Any hint on the right starting point(s)
>> > would
>> > be welcome...
>> >
>> > BTW : I have also had a (quite superficial) look at what pandas and
>> > statsmodel claim to do. They (and scikit-learn, which look interesting,
>> > and
>> > stan, already available from Python) might be indeed useful for
>> > run-of-the-mill descriptive analysis and regression models (and Stan for
>> > more exotic modeling). Packaging them for Sage might prove useful.
>> >
>> > However, those 9000+ R packages are here for a reason : if some of them
>> > (a
>> > small minority, IMHO) are obvious PhD-earning byproducts, others aim to
>> > solve difficult (if specialized) problems, badly solved (or not even
>> > considered) by the aforementioned trio. keeping a way to reach them from
>> > Sage might be important. Hence my plea for an "R interface(s)" package.
>> >
>> > Another (IMHO futile) reason for keeping an R interface in our arsenal
>> > is
>> > "name recognition" : quoting R in a "Materials and methods" section no
>> > longer raises questions from reviewers ; somehow, I doubt that pandas
>> > and
>> > statmodels get the same answer...
>> >
>> > What can you add ? Can someone propose a work plan ?
>>
>> I'm not thinking about politics and name recognition below - I'm just
>> providing a technical/engineering perspective.
>>
>> If anybody is seriously planning to work on the R pexpect interface, I
>> would personally suggest they consider instead working on the R
>> Jupyter kernel bridge instead, and 

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[William Stein]

On Sun, Oct 30, 2016 at 1:19 AM, Emmanuel Charpentier
 wrote:
> OK. It seems that a clear consensus exists for the excision of R _proprio
> dictu_ from Sage.
>
> If we break it, can we at least keep the (Sage's) pieces ? An optional
> package offering the current R interface(s) depending  on a systemwide(at
> least user-reachable) version of R and the R library might offer the
> functionality without entailing the (not so trivial) work of maintaining our
> own R port.
>
> Do you have an idea of the amount of work involved ? And how to, do it ? The
> rpy2 part is probably easy, but I expect surprises on the pexpec(t) front
> (at least if we want to keep compatibility with existing code using current
> R interface facilities...).  Any hint on the right starting point(s) would
> be welcome...
>
> BTW : I have also had a (quite superficial) look at what pandas and
> statsmodel claim to do. They (and scikit-learn, which look interesting, and
> stan, already available from Python) might be indeed useful for
> run-of-the-mill descriptive analysis and regression models (and Stan for
> more exotic modeling). Packaging them for Sage might prove useful.
>
> However, those 9000+ R packages are here for a reason : if some of them (a
> small minority, IMHO) are obvious PhD-earning byproducts, others aim to
> solve difficult (if specialized) problems, badly solved (or not even
> considered) by the aforementioned trio. keeping a way to reach them from
> Sage might be important. Hence my plea for an "R interface(s)" package.
>
> Another (IMHO futile) reason for keeping an R interface in our arsenal is
> "name recognition" : quoting R in a "Materials and methods" section no
> longer raises questions from reviewers ; somehow, I doubt that pandas and
> statmodels get the same answer...
>
> What can you add ? Can someone propose a work plan ?

I'm not thinking about politics and name recognition below - I'm just
providing a technical/engineering perspective.

If anybody is seriously planning to work on the R pexpect interface, I
would personally suggest they consider instead working on the R
Jupyter kernel bridge instead, and maybe create a drop in replacement
for the current pexpect interface that uses the R Jupyter kernel.
This would likely be time well spent. This is what we (mostly Hal
Snyder) have been doing with SageMathCloud, where now the %r mode in
Sage worksheets is implemented entirely using Jupyter (which we did
due to user bug/robustness reports with the sage pexpect interface):

   
https://github.com/sagemathinc/smc/blob/master/src/smc_sagews/smc_sagews/sage_jupyter.py

Some history -   I wrote those (stupid) pexpect interfaces in
2005-2006 as a way to bootstrap making Python talk to everything else.
However, they are basically the worst *viable* approach to the
problem.   Jupyter kernels are potentially a lot more work than using
pexpect, but they are clearly a better approach.

Yes, using pexpect is one way to write a Jupyter kernel, but
fortunately there are better ways.  For example, the Jupyter kernel is
1000(s) of lines of nontrivial  code written in the R language, which
is being improved all the time due to extensive use by users.  The
Jupyter R kernel is a serious actively developed project:

https://github.com/IRkernel/IRkernel

Compare that to the Sage R pexpect interface...

https://github.com/sagemath/sage/commits/master/src/sage/interfaces/r.py



 -- William


-- 
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.

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Emmanuel Charpentier]

OK. It seems that a clear consensus exists for the excision of R _proprio 
dictu_ from Sage.

If we break it, can we at least keep the (Sage's) pieces ? An optional 
package offering the current R interface(s) depending  on a systemwide(at 
least user-reachable) version of R and the R library might offer the 
functionality without entailing the (not so trivial) work of maintaining 
our own R port.

Do you have an idea of the amount of work involved ? And how to, do it ? 
The rpy2 part is probably easy, but I expect surprises on the pexpec(t) 
front (at least if we want to keep compatibility with existing code using 
current R interface facilities...).  Any hint on the right starting 
point(s) would be welcome...

BTW : I have also had a (quite superficial) look at what pandas and 
statsmodel claim to do. They (and scikit-learn, which look interesting, and 
stan, already available from Python) might be indeed useful for 
run-of-the-mill descriptive analysis and regression models (and Stan for 
more exotic modeling). Packaging them for Sage might prove useful.

However, those 9000+ R packages are here for a reason : if some of them (a 
small minority, IMHO) are obvious PhD-earning byproducts, others aim to 
solve difficult (if specialized) problems, badly solved (or not even 
considered) by the aforementioned trio. keeping a way to reach them from 
Sage might be important. Hence my plea for an "R interface(s)" package.

Another (IMHO futile) reason for keeping an R interface in our arsenal is 
"name recognition" : quoting R in a "Materials and methods" section no 
longer raises questions from reviewers ; somehow, I doubt that pandas and 
statmodels get the same answer...

What can you add ? Can someone propose a work plan ?

--
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+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.

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Dima Pasechnik]

On Friday, October 28, 2016 at 5:24:35 PM UTC, William wrote:
>
> On Fri, Oct 28, 2016 at 9:38 AM, Dima Pasechnik  > 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 
> >>  wrote: 
> >> > My thoughts so far : 
> >> > 
> >> > I : Is there really a problem ? 
> >> > = 
> >> > 
> >> > What all the brouhaha around libcurl boils down to is that there 
> *might* 

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Nathan Dunfield]

>
> It's ridiculous that we spend no effort on pandas/statsmodels, and all 
> this 
> effort on R.  


+1
 

> For example, I recall that there are some issues involving pandas + 
> statsmodels + the sage preparser.  
>

I use Pandas in the default Sage Interpreter on a daily basis and have only 
encountered a few quirks, all I think related to the Sage Integer vs. 
Python Integer distinction.  I don't use statsmodel though.  

Nathan

-- 
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.

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Matthias Koeppe]

On Friday, October 28, 2016 at 8:03:26 AM UTC-7, William wrote:
>
> we should **completely and totally remove R 
> from Sage**.  
>

We could also demote the R package to "optional" or "experimental" status.
I'd support that.
 

-- 
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.

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Dima Pasechnik]

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 
>  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, 

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[William Stein]

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.   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
 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 

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Jean-Pierre Flori]

On Friday, October 28, 2016 at 3:58:42 PM UTC+2, Volker Braun wrote:
>
> I think you are making it more difficult than it is. I'm pretty sure our 
> binaries already depend on openssl being installed, and we do this under 
> the GPL system library exception. We just can't ship our own openssl (nor 
> would I want to).
>
Yup that is most distro trick: considering openssl is part of the system 
lib of the operating system and invoke the corresponding GPL exception to 
link GPL stuff to it.
 
If our binaries already depends on openssl being installed, which I don't 
find really satisfactory, let it be and sotp the madness.
Not that if we want to ship binaries without this dependency it is not that 
hard (conifgure curl properly and a 10 line patch to R which won't support 
https).

-- 
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.

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Volker Braun]

I think you are making it more difficult than it is. I'm pretty sure our 
binaries already depend on openssl being installed, and we do this under 
the GPL system library exception. We just can't ship our own openssl (nor 
would I want to).

So we may just as well include libcurl, linked to the system openssl. 

The caveat of including libcurl is that neither curl nor openssl include 
the root certs, so to actually download over https:// on OSX you need those 
as well.

The other caveat of including libcurl is that it (by default) detects and 
links to everything under the sun, which we would have to disable somehow 
when building with SAGE_FAT_BINARY=yes

 $ ldd `which curl`
linux-vdso.so.1 (0x7ffcd5c7e000)
libcurl.so.4 => /lib64/libcurl.so.4 (0x7f0e6e644000)
libmetalink.so.3 => /lib64/libmetalink.so.3 (0x7f0e6e435000)
libssl3.so => /lib64/libssl3.so (0x7f0e6e1e8000)
libsmime3.so => /lib64/libsmime3.so (0x7f0e6dfc1000)
libnss3.so => /lib64/libnss3.so (0x7f0e6dc98000)
libnssutil3.so => /lib64/libnssutil3.so (0x7f0e6da69000)
libplds4.so => /lib64/libplds4.so (0x7f0e6d865000)
libplc4.so => /lib64/libplc4.so (0x7f0e6d66)
libnspr4.so => /lib64/libnspr4.so (0x7f0e6d42)
libpthread.so.0 => /lib64/libpthread.so.0 (0x7f0e6d204000)
libdl.so.2 => /lib64/libdl.so.2 (0x7f0e6d00)
libz.so.1 => /lib64/libz.so.1 (0x7f0e6cde9000)
libc.so.6 => /lib64/libc.so.6 (0x7f0e6ca27000)
libnghttp2.so.14 => /lib64/libnghttp2.so.14 (0x7f0e6c806000)
libidn.so.11 => /lib64/libidn.so.11 (0x7f0e6c5d1000)
libssh2.so.1 => /lib64/libssh2.so.1 (0x7f0e6c3a3000)
libpsl.so.5 => /lib64/libpsl.so.5 (0x7f0e6c196000)
libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x7f0e6bf48000)
libkrb5.so.3 => /lib64/libkrb5.so.3 (0x7f0e6bc62000)
libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x7f0e6ba31000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x7f0e6b82c000)
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x7f0e6b61d000)
libldap-2.4.so.2 => /lib64/libldap-2.4.so.2 (0x7f0e6b3cc000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x7f0e6b19f000)
librt.so.1 => /lib64/librt.so.1 (0x7f0e6af97000)
/lib64/ld-linux-x86-64.so.2 (0x557b0898)
libssl.so.10 => /lib64/libssl.so.10 (0x7f0e6ad24000)
libcrypto.so.10 => /lib64/libcrypto.so.10 (0x7f0e6a8c4000)
libunistring.so.2 => /lib64/libunistring.so.2 (0x7f0e6a594000)
libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x7f0e6a384000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x7f0e6a18)
libresolv.so.2 => /lib64/libresolv.so.2 (0x7f0e69f66000)
libsasl2.so.3 => /lib64/libsasl2.so.3 (0x7f0e69d48000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x7f0e69b21000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x7f0e698ea000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x7f0e69677000)
libfreebl3.so => /lib64/libfreebl3.so (0x7f0e69474000)

-- 
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.

Re: [sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

['Julien Puydt' via sage-devel]

Hi,

On 28/10/2016 15:39, Emmanuel Charpentier wrote:


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.


It's easy to ask:

https://www.debian.org/legal/

Snark on #debian-science

--
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.

[sage-devel] Re: R 3.3.1 depends on a SSL/TLS implementation

[Emmanuel Charpentier]

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