Skip to content

upgrading an R installation to next versoin

12 messages · Martin Maechler, Torsten Hothorn, Uwe Ligges +3 more

Original
Gabor Grothendieck
#
On 6/30/05, Gabor Grothendieck <ggrothendieck at gmail.com> wrote:
I have cleaned up my batch files (somewhat) and posted them to 
CRAN. See my recent post:
   https://www.stat.math.ethz.ch/pipermail/r-help/2005-July/073400.html

If any of this functionality could migrate to R itself that would be great.

1. In particular, if R could automatically look in ../R for *.site files if it
can't find them in .../R/rw..../etc and if it could look for a library
in .../R/library then Rrefresh.bat could be simplified to just refreshing
MiKTeX and makepkg.bat would not have to set the R_LIBS variable.

2. Also if Rcmd CHECK and Rcmd INSTALL were to process .Rbuildignore
like Rcmd BUILD does then makepkg.bat would not have to do a build first.
Martin Maechler
# 
.......................
  .......................

    Gabor> I have cleaned up my batch files (somewhat) and posted them to 
    Gabor> CRAN. See my recent post:
    Gabor> https://www.stat.math.ethz.ch/pipermail/r-help/2005-July/073400.html

    Gabor> If any of this functionality could migrate to R
    Gabor> itself that would be great.

    ........


    Gabor> 2. Also if Rcmd CHECK and Rcmd INSTALL were to
    Gabor> process .Rbuildignore like Rcmd BUILD does then
    Gabor> makepkg.bat would not have to do a build first.

No!  {We have been here before, and I had explained before that}
this is really undesired:  ".Rbuildignore" should contain what is
ignored by build, but not by "check".
It does make sense to have extra code and / or checks for 'R CMD check'
that I as package developer want to run, but that are
  -- too time consuming
  -- too platform specific
  -- ......
to be run during the daily checks on CRAN (e.g.) /
to be run by others at all.

{And BTW, AFAIK,  'Rcmd' is now `somewhat deprecated' in favor
 of "R CMD" since the latter is portable }

--
Martin
Gabor Grothendieck
#
On 7/6/05, Martin Maechler <maechler at stat.math.ethz.ch> wrote:
I think its too heavy handed an approach.  This should be up to the package
developer via a switch.  I like to put partially written code and other things
not intended for distribution in .Rbuildignore and don't want them checked or
installed until I move them out of .Rbuildignore.  That makes it
possible to keep
everything together.  Without this one must 1. keep them elsewhere
(which I am considering as an alternate approach to what I do now although 
it would be a shame) or else 2. write batch files (which I have
written for XP) to do
a prebuild every time one does a check or install.  

One annoying aspect of R CMD is the requirement for capitalization.  Maybe
that's ok on UNIX but on Windows one is used to using upper and lower
case interchangeably.  Its also annoying to have to write two words instead of
one for a frequently issued command.   At any rate I always call it through
my Rcmd.bat batch file so its not really an issue for me.
Torsten Hothorn
# 
I usually have something like

.onLoad <- function(lib, pkg) {
    ...
    GCtorture <<- TRUE
    ...
    return(TRUE)
}

in packages and simply

gctorture(on = GCtorture)

in all regression tests which allows me to switch between time consuming
tests and ordinary regression tests easily.

Torsten
Uwe Ligges
#
Gabor Grothendieck wrote:

            

      
      
      
    

        
Gabor, honestly, this is nonsense.

1. Do you expect that R also changes under Windows because you are used 
to mix upper and lower case and want to say SUMMARY() or rowsums()?
2. Do you really thing it is annoying to type "R CMD" rather than 
"Rcmd"? Hmm, anybody else has a space bar left for Gabor?

Best,
Uwe

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
Gabor Grothendieck wrote:

        

            

      
      
      
    

        
This is already implemented, just specify the environment variable 
R_PROFILE which points to your global site file. See ?Startup

            

      
      
      
    

        
Well, same as above, just set R_LIBS. You can do this for all sessions 
by using the windows control panel, you don't need to do it in each session.

Why do you expect others are using a setup like yours?
I do not. And I do not want R to look

            

      
      
      
    

        
Martin already pointed out why you should not really want this.

Uwe

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Gabor Grothendieck
    

    

      
      #
    

  


  

      
On 7/6/05, Uwe Ligges <ligges at statistik.uni-dortmund.de> wrote:

            

      
      
      
    

        
It was claimed its portable and that is true in the strictest sense that it
works on both UNIX and Windows but it would be even more
desirable if it were not just portable but also worked the way the target
system worked rather than just acting like a UNIX utility does
on Windows.  Ideally it would work as other Windows utilities work,
e.g. note that we run the following using upper and lower case and
get the same result:

C:> net use ?
The syntax of this command is:
NET USE
[devicename | *] [\\computername\sharename[\volume] [password | *]]
...

C:> NET USE ?
The syntax of this command is:
NET USE
[devicename | *] [\\computername\sharename[\volume] [password | *]]
...

A Windows user does not expect the case sensitive behaviour
since just about all the software one uses does not work that way.
I got tripped up by it myself and obviously others do too.  e.g. see
this recent post:
https://www.stat.math.ethz.ch/pipermail/r-help/2005-June/073154.html

I was just pointing out this undesirable aspect.  It may be a small point
but the sum of small inconsistencies can collectively amount to substantial
difficulty and contribute to the feeling that software is hard to use.

On the other point, I may be spacebar-challenged but Rcmd does address 
these points.

  
  


  


      

    

    

      
      

        


  

        

      Uwe Ligges
    

    

      
      #
    

  


  

      
Gabor Grothendieck wrote:

        

            

      
      
      
    

        
No! That something completely different: If Windows allows to use "net 
use" and "NET USE" even if only the latter is the documeted way, OK. 
These are, as you mentioned yourself, *Windows utilities* and you don't 
want to port this syntax.

But if you type "R cmd", it is no longer portable, and "Rcmd" for sure 
is not. "R CMD" is an R utility --- and R behaves case senstive.

Uwe Ligges

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Duncan Murdoch
    

    

      
      #
    

  


  

      
Uwe Ligges wrote:

            

      
      
      
    

        
In fact, on Windows R is not case sensitive in the 1st or 3rd word on 
the line "R CMD install", only in the 2nd, so I can see Gabor's point. 
However, I have to admit I always use "Rcmd install"; I put the "R CMD 
..." version in place to help Unix refugees.

Duncan Murdoch

  
  


  


      

    

    

      
      

        


  

        

      Gabor Grothendieck
    

    

      
      #
    

  


  

      
On 7/6/05, Uwe Ligges <ligges at statistik.uni-dortmund.de> wrote:

            

      
      
      
    

        
The desirable philosophy when it comes to portability is that software
works in the way the host system works, not in a new way that the
software defines for itself for all systems.  The problems I and the
cited poster had in this regard well illustrate the problem with the current
approach.

  
  


  


      

    

    

      
      

        


  

        

      Gabor Grothendieck
    

    

      
      #
    

  


  

      
On 7/6/05, Uwe Ligges <ligges at statistik.uni-dortmund.de> wrote:

            

      
      
      
    

        
Thanks.  This is useful to know.   At the same time the (unstated) philosophy
of the batchfiles is that no environment variables need to be explicitly set in
your system other than ones that are required by the package-making 
tools themselves (Perl, MiKTeX).    Also the existence
of R_PROFILE is nice but does not fully address the point I made since it
still requires that you set R_PROFILE. With the point I was
making nothing at all would have to be done.

There is also some question as to whether one wants the same *.site 
files for all versions of R on the system.  The way the batch files currently 
work is that each R version on your system can have its own *.site files 
although that is a potential disadvantage of my suggestion too.

I will think this over but will likely modify the batch files to incorporate
your idea so that they temporarily set R_PROFILE for the duration of their 
run if not already set.  This would simplify the procedure in that one would
not have to run Rrefresh.bat when the *.site files change (but would
still have to run it to update MiKTeX when a new version of R was installed).

            

      
      
      
    

        
Again this is an extra step by the user and it pollutes the system with
yet another environment variable.  Currently the makepkg.bat sets it
for the duration of the build/check/install (unless it was already set).

            

      
      
      
    

        
No one need use my setup but it does have the advantage of simplicity.
One can use a vanilla MiKTeX install avoiding significant potential complexity
in using MiKTex, no environment variables need to be set in your system 
other than those needed by the tools themelves and one does not have to do 
any reconfiguration each time one installs a new version of R other than
just run Rrefresh.bat without arguments.  In fact with the addition of the
R_PROFILE idea it will likely work OK even if you forget that step since
it only updates MiKTeX and MiKTeX files probably have not changed 
on a typical new R version anyway.  Also the batch files include Rfind.bat
which locates the various tools needed by R package developers which
helps organize oneself.

            

      
      
      
    

        
and, of course, I explained why would want to.  In particular since obviously
this had no impact let me point out that not only is this desirable for one's
own work so that partially done files do not affect the check and install
but it is also desirable when one is working on a package in a group
communicating via svn.  In that case its easiest if one just shares the package
source and can label the incomplete files via .Rbuildignore and share them via 
svn but not have them affect the check and install. 

Its likely that .Rbuildignore is being used for multiple unanticipated
purposes here (those discussed by Martin and those by myself) and one
either needs the flag/switch I suggested or perhaps a more powerful
facility that ecompasses these multiple uses.

  
  


  


      

    

    
1 day later

    

      
      

        


  

        

      Seth Falcon
    

    

      
      #
    

  


  

      
On  6 Jul 2005, murdoch at stats.uwo.ca wrote:

            

      
      
      
    

        
And this is appreciated by those of us that want to build packages on
different platforms in an automated fashion :-)

Although I agree with other posters in this thread that ports
generally work best when they behave as natively as possible, it is
the case that many R users use R on *both* Windows and Linux and
because of this, the consistency is very helpful.

+ seth