Allow the use of system's R installation

[sagetrac-tmonteil]

The aim of this ticket is to allow Sage to use the system's R, instead of building its own.

It should work for:

• sage -R command
• Sage's r interface
• Sage's rpy2 Python package
• Sage's jupyter IRkernel

Similarly to the way one can decide to use the system ATLAS when building Sage,
on the user side, building Sage so that it uses the system R is achieved by setting
the SAGE_R_LIB environment variable.

To test this ticket, you should at least:

• install R on your system (e.g. sudo apt install r-base)
• reinstall r and rpy2 with SAGE_R_LIB set:

export SAGE_R_LIB=/usr/lib/R/
sage -f r
sage -f rpy2
make build

• test Sage R command (this should/might show a different version than 3.4.4):

sage -R

• test Sage's R interface:

sage -t --long src/sage/interfaces/r.py

• test rpy2:

sage -t --long src/sage/stats/r.py

CC: @EmmanuelCharpentier @embray @kiwifb @kcrisman @slel @timokau @orlitzky

Component: packages: standard

Keywords: R, sdl

Author: Thierry Monteil

Branch/Commit: u/tmonteil/allow_the_use_of_system_s_r_installation @ eed2ea3

Reviewer: Dima Pasechnik

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

[sagetrac-tmonteil]

Branch: u/tmonteil/allow_the_use_of_system_s_r_installation

[sagetrac-tmonteil]

New commits:

380a2b0	#25503 : do not build R if SAGE_R_LIB is set
e8768ed	#25503 : let rpy2 use SAGE_R_LIB for its RHOMES variable
0519cda	#25503 : fix issue between R interface and readline 7
eed2ea3	#25503 : document the SAGE_R_LIB variable in the install guide

[sagetrac-tmonteil]

Commit: eed2ea3

[sagetrac-tmonteil]

comment:4

We should probably also update sage-env script, which explicitly unset R-related variables that the user could set in relation with system-wide install.

[slel]

Changed keywords from none to R

[novoselt]

comment:6

So - if a system-wide install is used, does it mean that the standard R configuration files will be picked up? With its own R Sage makes sure that nothing is used.

[sagetrac-tmonteil]

comment:7

Replying to @novoselt:

So - if a system-wide install is used, does it mean that the standard R configuration files will be picked up?

I would say yes (see my last comment about sage-env), though i might be wrong. I guess that if a user explicitly ask Sage to use system-wide R, it means that she want to keep all control (e.g. on where to install things, etc).

[sagetrac-tmonteil]

comment:9

Replying to @novoselt:

So - if a system-wide install is used, does it mean that the standard R configuration files will be picked up?

Yes.

With its own R Sage makes sure that nothing is used.

It is up to the user to decide whether she wants to use the system's R or Sage's R, the default remains to build and use Sage's R.

[saraedum]

comment:10

I would be curious to hear embray's opinion on this. I know that he has been working on allowing to use system packages more generally.

Btw, there are merge conflicts.

[jhpalmieri]

comment:11

Why should this work for the sage -R command? That command is explicitly documented (as in sage --help and in the reference manual) to "run Sage's R with given arguments", so why should it run a non-Sage R? Maybe I'm misunderstanding.

I think that any installation of Sage which does not install its own R, Python, Singular, etc., should not have functioning sage --python, sage -R, sage --singular, etc., commands. Maybe instead, those commands should provide good error messages if Sage is configured to use a system version of the appropriate software.

But if you really want sage -R to work with a non-Sage version of R, please change the documentation.

[kiwifb]

comment:12

I never changed those help messages in sage-on-gentoo. There is an ambiguity I am exploiting. You think it only means R from sage the distribution, I take it to mean R that sage has been configured to use. You could argue that the capitalisation means we are talking about the distribution.

Should we have a semantic war :)

In any case, while there is no real benefit, compared to running R directly, I don't see why the behavior shouldn't be preserved. Existing scripts shouldn't break because you changed some underlying bits.

[kiwifb]

comment:13

Seriously, if changing the documentation is your only problem with this, I'd be glad to just do that. Do you have a preferred wording?

[jhpalmieri]

comment:14

I think that if the system has R installed, people should run it by running R, not sage -R. So I think if Sage is going to use the system's R, there is no need for command sage -R – it adds the 6 extra characters sage - for no reason – and it should be disabled.

[kiwifb]

comment:15

Replying to @jhpalmieri:

I think that if the system has R installed, people should run it by running R, not sage -R. So I think if Sage is going to use the system's R, there is no need for command sage -R – it adds the 6 extra characters sage - for no reason – and it should be disabled.

So you don't think we should support people with old script that may call sage -R? You want those people to update?

[jhpalmieri]

comment:16

If Sage is not going to install a copy of R, then you could rewrite the main sage script so that sage -R prints a deprecation warning before executing the system's R`.

I don't really buy your ambiguity argument, and I think that you are misleading people if sage -R runs a version of R which was not installed by Sage. (There is also the slim chance that it won't work and people will report errors from running sage -R to Sage developers, or (even worse) silently blame us for the problem, when it has nothing to do with us.)

How many people really use commands like sage -R? Maybe they should all be deprecated, and people should be encouraged to put SAGE_ROOT/local/bin in their path or instead to use sage --sh -c blah, where blah can be R or python or ecl or ...

If you really want to proceed, note that sage -h contains

  -cython [...]       -- run Cython with given arguments
  -ecl [...]          -- run Common Lisp
  -gap [...]          -- run Sage's Gap with given arguments

so maybe they should all omit "Sage's". I won't be happy with that change, so you'll need another reviewer, and I also think you should ask for more opinions.

[timokau]

comment:17

For what its worth I agree with @kiwifb's interpretation. Even a distro can have multiple versions of a dependency installed. Sometimes it can be useful to "start the R sage uses", for example for debugging.

[slel]

comment:18

I would also agree with interpreting "Sage's R" as "the R that Sage has been configured to use",
and similarly for GAP, PARI/GP, Singular, etc.

[kiwifb]

comment:19

I think John feels very strongly about his interpretation. The heart of his argument being if it says it is sage's own, the sage devs owns the bugs. As distros guys we all know where to stand about that.

Sometimes it is your own bugs (build system, distro specificities) and sometimes it belong to upstream. In any case you may carry patches and sage-the-distro has a long history about "owning" its own patches regardless of upstream as you well know.

In any case piping on the matter on sage-devel doesn't cost us much since it is now, in effect, a sage-8.5 ticket.

[timokau]

comment:20

I don't feel very strongly about it either way, maybe printing a clear information (either "this is a sage package" or "this is a system package") first is a good compromise.

[embray]

comment:21

Replying to @jhpalmieri:

I think that any installation of Sage which does not install its own R, Python, Singular, etc., should not have functioning sage --python, sage -R, sage --singular, etc., commands. Maybe instead, those commands should provide good error messages if Sage is configured to use a system version of the appropriate software.

But if you really want sage -R to work with a non-Sage version of R, please change the documentation.

I disagree. I think these commands should really just mean "run the same Python/R/etc. that Sage is using, with all the sage-related environment variables set".

[embray]

comment:22

Replying to @jhpalmieri:

I think that if the system has R installed, people should run it by running R, not sage -R. So I think if Sage is going to use the system's R, there is no need for command sage -R – it adds the 6 extra characters sage - for no reason – and it should be disabled.

That's not true that there is no reason for it. For example, what if you want to run R in the Sage environment so that you can run sage commands in R with RPy? Or interface with other software that is included in the Sage distribution? From the user's perspective, sage -R means "launch the R that sage is using". It's transparent/irrelevant whether or not the R command happened to be included in the Sage distribution or not. For downstream distributions (e.g. on Debian, Gentoo) they are all using the system's copies of programs as much as possible, so you'll just have confused users who find that sage -R works on some system but not others.

[sagetrac-tmonteil]

Changed keywords from R to R, sdl

[dimpase]

comment:25

I've opened #28884 with a working (on Debian at least) branch allowing use of system's R.

Feel free to review.

[orlitzky]

comment:26

Is there still anything to do here? I don't really use R inside or outside of sage... has #28884 caused any problems?

[dimpase]

comment:27

not sure about Jupyter kernel for R, but this is a different story. A new ticket, if you must.

[dimpase]

Reviewer: Dima Pasechnik