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

Whit Armstrong armstrong.whit at gmail.com
Thu Sep 16 20:05:35 CEST 2010


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:
> On Sep 16, 2010, at 10:06 AM, Vinh Nguyen wrote:
>
>> 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 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 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 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'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.
>>
>
> 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
>
>
>
>
>> 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
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



More information about the R-devel mailing list