Skip to content

advice on writing/maintaining an R package with a version control system

3 messages · Vinh Nguyen, Simon Urbanek, Whit Armstrong

Original
Vinh Nguyen
# 
Dear all,

As I resume my dissertation work next month, I'd like to actually
start an R package this time around.  I haven't done so because I
update my code very often (still in development phase), so running the
skeleton function, running checks, building, and re-installing the
package onto the system seemed like a long and tedious process.

I would like to hear your experience on how you start an R package
with a version control system.  Currently, I have most of my functions
in an R source file.  I expect to use a skeleton function to generate
the package directory (most likely Rcpp's), and start git as my
version control system (although the advice I'm seeking isn't
git-specific).  Once the version control system is set up, a few
questions:

1.  Do you update your code directly into the multiple R files in
./src, or do you update the main R source file?  I'm assuming the
former since we're using version control.
2.  What is your process for updating and testing your code?  Do you
run checks, build, and re-install the package to test?  Or do you have
some fancy workflow?  Please share.

Thanks for your advice.

Vinh
--
Vinh Nguyen
Department of Statistics
Donald Bren School of ICS
2231 Bren Hall
University of California, Irvine
Irvine, CA 92607
vqnguyen at uci.edu | http://www.ics.uci.edu/~vqnguyen/
Schedule a meeting: http://tungle.me/VinhNguyen
Simon Urbanek
#
On Sep 16, 2010, at 10:06 AM, Vinh Nguyen wrote:

            

      
      
      
    

        
I guess it depends on the package, but in general I find it's so fast that it's not worth bothering with the alternatives. It's just one line to build, install a package and run the desired test code. The time to do that is usually in single-digit seconds which I'm happy with.

            

      
      
      
    

        
I suspect you mean ./R not ./src if it's an R source file. Personally, I group functions by topic into files, some others put one function per file - it's all about personal preferences because the installed package won't have any of the files you're using so technically it doesn't matter.

            

      
      
      
    

        
I just run
R CMD build xxx && R CMD INSTALL xxx && R
sometimes also including the test code in the last R call so running it requires pressing only two keys. Once I'm happy that the stuff seems to work I run the checks and then commit. (If I'm confident I commit right away since I use SVN and my RForge does run checks on commit so I don't have to bother doing that - it also checks on a different system which is good in case you forgot to add files to the VCS).

If you have large or complex packages, it may be useful to just change a function at a time in the interactive session -- but that's trivial as you simply send the assignment from your editor. (Some tricks may be needed if namespaces are involved but they are usually simple ways around).

Just my very personal $0.02.

Cheers,
Simon

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Whit Armstrong
    

    

      
      #
    

  


  

      
Since you are using git you may want to consider a submodule for your project.

It is often helpful to build a full library in c++ complete with it's
own unit tests.

You can then package this library inside of your R project as a submodule.

This can speed up the testing phase of the project b/c you don't have
to recompile and install the package every time you need to patch/test
your code.

For examples, see fts: http://github.com/armstrtw/fts.

-Whit


On Thu, Sep 16, 2010 at 11:15 AM, Simon Urbanek

        
<simon.urbanek at r-project.org> wrote: