On Tue, 2009-04-07 at 12:09 +0200, Martyn Plummer wrote: > > I see two points, either we help the user by setting the R_HOME ourself > > directly within R and rjava works directly or we do not and let set > > R_HOME which he will do anyway to make rjava working... > > How does it help the user to set R_HOME? By user I meant anyone who is willing to use rJava in any of its capacity (including the JRI interface). That mean: people that develop application using rJava or people that use that application.
> > The rJava package does two things: > 1) It allows the R user to call java functions from within R. > 2) It allows applications written in java to start an instance of the R > engine and pass data and commands back and forth. > > It is the second use (the JRI interface) that concerns us. There are > three parties in this situation: > 1) R > 2) The user > 3) A third party java application. > > The responsibility for setting R_HOME lies firmly with the third-party > application, which should launch from within its own shell, within which > R_HOME is set to the appropriate value. This value should be determined > when the application is configured. Yes but since JRI does not do it automatically, the developer and thus the user have to set a R_HOME by hand. The proof is that this run scrip starts by setting R_HOME... > The user should never have to set > it. I totally agree. I would even say that the JRI interface should be able to determine what is R_HOME directly by asking R. > > > Is there not a way for the testing suite of the development version to > > test if R_HOME is already set ? > > Setting R_HOME in the environment before launching R is the wrong > thing to do. Just out of curiosity, why ? R_HOME should be coherent between the environment and R itself, through a warning if they are different makes sense (IMHO), but if they are the same what is the problem ? Regards, Pierre _______________________________________________ Fedora-r-devel-list mailing list Fedora-r-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
