Handle preset R_PROFILE or R_HOME variables

[mpatel]

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.

[mpatel]

From around line 180 of SAGE_LOCAL/bin/sage-env:

if [ -z "$RHOME" ]; then
    RHOME="$SAGE_LOCAL/lib/R" && export RHOME
fi

Should we add a similar test for R_PROFILE?

[leif]

I think we should perhaps

unset R_PROFILE

in R's spkg-install, too.

[kcrisman]

Apparently this might be addressed by a solution to #9906.

[leif]

Replying to leif:

I think we should perhaps

unset R_PROFILE

in R's spkg-install, too.

#9906 (R 2.10.1.p5) does this now.

[kcrisman]

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.

[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!

Sound good? ;-) But I don't think that will be necessary.

[leif]

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.

[kcrisman]

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

[jdemeyer]

I order to finally finish #9906, I decided not to add this change anymore.

[kcrisman]

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.

[kcrisman]

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.

[jdemeyer]

Replying to kcrisman:

And the R_HOME and R_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.

[kcrisman]

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?