Jupyter R kernel

[vbraun]

This introduces a new "script" type of packages that only run a script. This is supposed to be an alternative for optional/experimental packages so we can use third-party package managers to install things.

In this case, the R package manager, though it would presumably be useful for TexLive (instead of src/ext/texlive/texlive-install) and npm. But thats for future tickets...

CC: @jdemeyer @EmmanuelCharpentier

Component: packages: optional

Author: Volker Braun

Branch/Commit: 7316730

Reviewer: Emmanuel Charpentier

Issue created by migration from https://trac.sagemath.org/ticket/19427

[vbraun]

Branch: u/vbraun/jupyter_r_kernel

[vbraun]

Author: Volker Braun

[vbraun]

New commits:

305f3e6	Add new "script" type for packages
2958d58	Install script for the R Jupyter kernel

[vbraun]

Commit: 2958d58

[vbraun]

comment:3

Note: need to bootstrap before the new make target is available, but since this is not urgent it can wait for the next beta release.

[jdemeyer]

comment:4

Could you please add a dependencies file (I guess this just depends on R).

[vbraun]

comment:5

scripts depend on all standard packages (just like optional ones). It also depends on jupyter as it calls it to install its kernel specs. On the one hand it would be nice to have the dependencies explicit, but they would also just be wrong if we can't actually test them.

[jdemeyer]

comment:6

Replying to @vbraun:

if we can't actually test them.

This describes a way to test dependencies:
http://doc.sagemath.org/html/en/developer/packaging.html#package-dependencies

If make distclean && make base && make PACKAGE_NAME succeeds, the dependencies are probably correct.

I would certainly like to make dependencies mandatory, I am in the process of adding missing dependency files (see for example #19295).

[vbraun]

comment:7

Still, whats the point? Some packages can't be standard so depending on standard doesn't cost us anything. Whereas additional complexity, new ways of introducing dependency errors, and insufficient test coverage are very real downsides.

[jdemeyer]

comment:8

Shouldn't the spkg-install script be run within a Sage shell at least?

[sagetrac-git]

Changed commit from 2958d58 to ef5a125

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

8074932	Add new "script" type for packages
0282c7e	Install script for the R Jupyter kernel
ef5a125	Source sage-env before running spkg-install script

[vbraun]

New commits:

8074932	Add new "script" type for packages
0282c7e	Install script for the R Jupyter kernel
ef5a125	Source sage-env before running spkg-install script

[EmmanuelCharpentier]

Attachment: Untitled3-native.pdf.gz

A few notebook commands with 6.10rc0+Trac#19427

[EmmanuelCharpentier]

A few notebook commands with 6.10rc0+Trac#19638(rpy2 update)+ manual installation of IRKernel

[EmmanuelCharpentier]

comment:11

Attachment: Untitled3-19638.pdf.gz

Dear Volker,

1. Great idea ! I am sure a lot of use cases exist in the Sagemath ecosystem.

2. Your ticket (tested against a fresh clone of 6.10rc0) :

• builds, and
• passes ptestlong.
• Installing r_jupyter effectively installs an R kernel in Sagemath's Jupyter notebook.
• This notebook is functional (i. e. one can create a worksheet whose native language is R).

3. However, over Sage 6.10rcO, the Rpy2 interface cannot be used in a Sagemath notebook :

• The "%load_ext rpy2.ipython" command is not recognized
• The "%load_ext rmagic" command is recognized (with a warning), but :
• The %R (and %%R) commands are not recognized

You can compare these results (illustrated in "Untitled3-native.pdf") with those obtained on 6.10rc0+Trac#19638+manual installation of IRKernel in R, which also illustrates the problems with this current implementation :

• uses a different instance of R than the Sage's pexpect interface
• converts the output in strange formats, different from those used by Sages's pexpect interface.

If your goal was strictly limited to providing an R notebook in Sage's Jupyter, I think it's good to go. If you aimed at providing Sage with an alternative interface to R, it needs work (needs Trac#19638, IMHO, but I'm biased...).

I would be interested in your point of view in the question I posed in sage-devel. William's sarcastic non-answer misses a part of the point.

Sincerely yours,

[vbraun]

comment:12

This ticket has nothing to do with rpy2, its only about the jupyter R kernel. Really they are two totally independent approaches to using R, one from within Python and the other without Python.

[EmmanuelCharpentier]

Reviewer: Emmanuel Charpentier

[EmmanuelCharpentier]

comment:13

Replying to @vbraun:

This ticket has nothing to do with rpy2, its only about the jupyter R kernel. Really they are two totally independent approaches to using R, one from within Python and the other without Python.

[ Sorry for the delay. I was busy... ]

Okay. This clarification (that should go in the description) enables positive review.

[sagetrac-git]

Branch pushed to git repo; I updated commit sha1 and set ticket back to needs_review. This was a forced push. New commits:

ba549f3	Add new "script" type for packages
753f7bc	Install script for the R Jupyter kernel
4990f59	Source sage-env before running spkg-install script
7316730	Bump confball version since configure.ac changed

[sagetrac-git]

Changed commit from ef5a125 to 7316730

[vbraun]

Changed branch from u/vbraun/jupyter_r_kernel to 7316730