Opened 2 years ago

Closed 3 months ago

#25503 closed defect (duplicate)

Allow the use of system's R installation

Reported by: tmonteil Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: packages: standard Keywords: R, sdl
Cc: charpent, embray, fbissey, kcrisman, slelievre, gh-timokau, mjo Merged in:
Authors: Thierry Monteil Reviewers: Dima Pasechnik
Report Upstream: N/A Work issues:
Branch: u/tmonteil/allow_the_use_of_system_s_r_installation (Commits) Commit: eed2ea352af29fa6e6fb65d274c2e0078a7c07a6
Dependencies: Stopgaps:

Description (last modified by slelievre)

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
    

Change History (28)

comment:1 Changed 2 years ago by tmonteil

  • Branch set to u/tmonteil/allow_the_use_of_system_s_r_installation

comment:2 Changed 2 years ago by tmonteil

  • Cc charpent embray added
  • Commit set to eed2ea352af29fa6e6fb65d274c2e0078a7c07a6
  • Description modified (diff)
  • Status changed from new to needs_review

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

comment:3 Changed 2 years ago by tmonteil

  • Description modified (diff)

comment:4 Changed 2 years ago by tmonteil

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.

comment:5 Changed 2 years ago by slelievre

  • Cc fbissey kcrisman slelievre added
  • Description modified (diff)
  • Keywords R added

comment:6 follow-ups: Changed 2 years ago by novoselt

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.

comment:7 in reply to: ↑ 6 Changed 2 years ago by tmonteil

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

comment:8 Changed 2 years ago by gh-timokau

  • Cc gh-timokau added

comment:9 in reply to: ↑ 6 Changed 2 years ago by tmonteil

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.

comment:10 Changed 21 months ago by saraedum

  • Status changed from needs_review to needs_work

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.

comment:11 follow-up: Changed 21 months ago by jhpalmieri

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.

Last edited 21 months ago by jhpalmieri (previous) (diff)

comment:12 Changed 21 months ago by fbissey

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.

comment:13 Changed 21 months ago by fbissey

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?

comment:14 follow-ups: Changed 21 months ago by 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.

comment:15 in reply to: ↑ 14 Changed 21 months ago by fbissey

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?

comment:16 Changed 21 months ago by jhpalmieri

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.

comment:17 Changed 21 months ago by gh-timokau

For what its worth I agree with @fbissey'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.

comment:18 Changed 21 months ago by slelievre

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.

comment:19 Changed 21 months ago by fbissey

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.

comment:20 Changed 21 months ago by gh-timokau

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.

comment:21 in reply to: ↑ 11 Changed 21 months ago by embray

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

comment:22 in reply to: ↑ 14 Changed 21 months ago by embray

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.

comment:23 Changed 21 months ago by embray

  • Milestone changed from sage-8.3 to sage-wishlist

comment:24 Changed 10 months ago by tmonteil

  • Keywords sdl added

comment:25 Changed 7 months ago by dimpase

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

Feel free to review.

comment:26 Changed 4 months ago by mjo

  • Cc mjo added

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

comment:27 Changed 4 months ago by dimpase

  • Milestone changed from sage-wishlist to sage-duplicate/invalid/wontfix
  • Reviewers set to Dima Pasechnik
  • Status changed from needs_work to positive_review

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

comment:28 Changed 3 months ago by chapoton

  • Resolution set to duplicate
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.