Opened 11 years ago
Closed 8 years ago
#9847 closed defect (fixed)
Handle preset R_PROFILE or R_HOME variables
Reported by: | mpatel | Owned by: | GeorgSWeber |
---|---|---|---|
Priority: | blocker | Milestone: | sage-5.9 |
Component: | build | Keywords: | |
Cc: | ggrafendorfer, kcrisman | Merged in: | sage-5.9.beta2 |
Authors: | Jeroen Demeyer | Reviewers: | Leif Leonhardy, Karl-Dieter Crisman |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | Stopgaps: |
Description (last modified by )
A preset R_PROFILE
variable can cause some R packages to fail to build/install and interfere with doctests.
Georg Grafendorfer reported this problem on sage-release.
For R_HOME
, this yields a doctest failure if set:
********************************************************************** File "devel/sage/sage/misc/interpreter.py", line 187, in sage.misc.interpreter.SageInteractiveShell.system_raw Failed example: shell.system_raw('R --version') Expected: R version ... Got: WARNING: ignoring environment value of R_HOME R version 2.15.2 (2012-10-26) -- "Trick or Treat" Copyright (C) 2012 The R Foundation for Statistical Computing ISBN 3-900051-07-0 Platform: x86_64-unknown-linux-gnu (64-bit) <BLANKLINE> R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under the terms of the GNU General Public License versions 2 or 3. For more information about these matters see http://www.gnu.org/licenses/. <BLANKLINE> **********************************************************************
Apply 9847_unset_R.patch to SAGE_ROOT
.
Attachments (1)
Change History (22)
comment:1 Changed 11 years ago by
comment:2 follow-up: ↓ 4 Changed 11 years ago by
I think we should perhaps
unset R_PROFILE
in R's spkg-install
, too.
comment:3 Changed 11 years ago by
Apparently this might be addressed by a solution to #9906.
comment:4 in reply to: ↑ 2 Changed 10 years ago by
- Dependencies set to #9906
- Milestone set to sage-duplicate/invalid/wontfix
- Status changed from new to needs_review
comment:5 Changed 10 years ago by
Thanks. Trac isn't sending emails, as you know, so I just saw this. (Well, six hours isn't bad.) I'll take a look at #9906 then.
comment:6 follow-up: ↓ 7 Changed 10 years ago by
- Reviewers set to Leif Leonhardy, Karl-Dieter Crisman
Sorry I didn't come back to this. It is correct that the spkgs at #9906 do this in the spkg scripts.
So I can give this positive review as long as Leif promises that if I or some other reviewer find out that the fix at #9906 doesn't solve the type of problem above, that it will get addressed there and no longer here!
Sound good? ;-) But I don't think that will be necessary.
comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 10 years ago by
Replying to kcrisman:
Sorry I didn't come back to this. It is correct that the spkgs at #9906 do this in the spkg scripts.
So I can give this positive review as long as Leif promises that if I or some other reviewer find out that the fix at #9906 doesn't solve the type of problem above, that it will get addressed there and no longer here!
In that case, you should also give this ticket positive review, such that the release manager will close it, with "resolution: duplicate".
If issues with R_PROFILE
should (re)arise unrelated to (the installation of) the R spkg, i.e., which would have to be fixed elsewhere, we can still reopen this ticket.
(IIRC some of the problems showed up during doctesting, but because R_PROFILE
had been set during installation, so are now fixed by the new spkg. If there needs to be done more w.r.t. this -- which I don't think -- this can be addressed at #9906 as Karl-Dieter suggests.)
Note that this ticket already has #9906 as its dependency.
comment:8 in reply to: ↑ 7 Changed 10 years ago by
- Status changed from needs_review to positive_review
So I can give this positive review as long as Leif promises that if I or some other reviewer find out that the fix at #9906 doesn't solve the type of problem above, that it will get addressed there and no longer here!
In that case, you should also give this ticket positive review, such that the release manager will close it, with "resolution: duplicate".
Correct. I just wanted to make sure :) Great.
(IIRC some of the problems showed up during doctesting, but because
R_PROFILE
had been set during installation, so are now fixed by the new spkg. If there needs to be done more w.r.t. this -- which I don't think -- this can be addressed at #9906 as Karl-Dieter suggests.)
Yeah, I'm pretty sure that was the issue, or more precisely that R_PROFILE
was not (re)set.
Note that this ticket already has #9906 as its dependency.
Well, that wouldn't be necessary with a duplicate/wontfix one.
See you at #9906, eventually (when I get time to do all the many tests on that).
comment:9 Changed 10 years ago by
- Resolution set to duplicate
- Status changed from positive_review to closed
comment:10 Changed 9 years ago by
- Milestone changed from sage-duplicate/invalid/wontfix to sage-5.4
- Resolution duplicate deleted
- Status changed from closed to new
comment:11 Changed 9 years ago by
I order to finally finish #9906, I decided not to add this change anymore.
comment:12 Changed 9 years ago by
Ok. What was the solution there - simply unset R_PROFILE
in its spkg-install as suggested in comment:2, or something more involved like in comment:1 (sage-env), or both, or... after reading Leif's comments and Georg's diagnosis in the thread in the description, maybe the simplest solution will be best.
comment:13 Changed 8 years ago by
- Description modified (diff)
- Summary changed from Handle a preset R_PROFILE variable to Handle a preset R_PROFILE or R_HOME variables
comment:14 Changed 8 years ago by
- Priority changed from major to blocker
Changed 8 years ago by
comment:15 Changed 8 years ago by
- Description modified (diff)
comment:16 follow-up: ↓ 17 Changed 8 years ago by
Looks good, based on the various discussions in question.
And the R_HOME
and R_PROFILE
will be "reset" after one exits the Sage shell, correct? I do know that some people use their own custom R packages (or try to) but I guess that isn't supported behavior, given the structure of Sage.
In that case, applies and presumably works (I certainly can't test this, but based on all the above) so we should get this in, at long last.
comment:17 in reply to: ↑ 16 Changed 8 years ago by
Replying to kcrisman:
And the
R_HOME
andR_PROFILE
will be "reset" after one exits the Sage shell, correct?
Sure, although nothing is really "reset", you just get your old shell back which never saw sage-env
.
comment:18 Changed 8 years ago by
- Status changed from new to needs_review
Fair enough. I think this is a realistic solution to this; I don't think we have to support combinations of these environments. If someone really wanted to, they could set these things in init.sage
, right?
comment:19 Changed 8 years ago by
- Dependencies #9906 deleted
- Status changed from needs_review to positive_review
comment:20 Changed 8 years ago by
- Summary changed from Handle a preset R_PROFILE or R_HOME variables to Handle preset R_PROFILE or R_HOME variables
comment:21 Changed 8 years ago by
- Merged in set to sage-5.9.beta2
- Resolution set to fixed
- Status changed from positive_review to closed
From around line 180 of
SAGE_LOCAL/bin/sage-env
:Should we add a similar test for
R_PROFILE
?