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.urba...@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 >> vqngu...@uci.edu | http://www.ics.uci.edu/~vqnguyen/ >> Schedule a meeting: http://tungle.me/VinhNguyen >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
