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.
