Opened 3 years ago
Closed 18 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, GitHub, GitLab) | Commit: | eed2ea352af29fa6e6fb65d274c2e0078a7c07a6 |
Dependencies: | Stopgaps: |
Description (last modified by )
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
andrpy2
withSAGE_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 3 years ago by
- Branch set to u/tmonteil/allow_the_use_of_system_s_r_installation
comment:2 Changed 3 years ago by
- Cc charpent embray added
- Commit set to eed2ea352af29fa6e6fb65d274c2e0078a7c07a6
- Description modified (diff)
- Status changed from new to needs_review
comment:3 Changed 3 years ago by
- Description modified (diff)
comment:4 Changed 3 years ago by
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 3 years ago by
- Cc fbissey kcrisman slelievre added
- Description modified (diff)
- Keywords R added
comment:6 follow-ups: ↓ 7 ↓ 9 Changed 3 years ago by
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 3 years ago by
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 3 years ago by
- Cc gh-timokau added
comment:9 in reply to: ↑ 6 Changed 3 years ago by
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 3 years ago by
- 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: ↓ 21 Changed 3 years ago by
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.
comment:12 Changed 3 years ago by
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 3 years ago by
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: ↓ 15 ↓ 22 Changed 3 years ago by
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 3 years ago by
Replying to jhpalmieri:
I think that if the system has
R
installed, people should run it by runningR
, notsage -R
. So I think if Sage is going to use the system'sR
, there is no need for commandsage -R
– it adds the 6 extra characterssage -
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 3 years ago by
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 3 years ago by
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 3 years ago by
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 3 years ago by
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 3 years ago by
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 3 years ago by
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 ofR
, 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 3 years ago by
Replying to jhpalmieri:
I think that if the system has
R
installed, people should run it by runningR
, notsage -R
. So I think if Sage is going to use the system'sR
, there is no need for commandsage -R
– it adds the 6 extra characterssage -
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 3 years ago by
- Milestone changed from sage-8.3 to sage-wishlist
comment:24 Changed 2 years ago by
- Keywords sdl added
comment:25 Changed 22 months ago by
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 18 months ago by
- 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 18 months ago by
- 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 18 months ago by
- Resolution set to duplicate
- Status changed from positive_review to closed
New commits:
#25503 : do not build R if SAGE_R_LIB is set
#25503 : let rpy2 use SAGE_R_LIB for its RHOMES variable
#25503 : fix issue between R interface and readline 7
#25503 : document the SAGE_R_LIB variable in the install guide