How to use git in R package development?

Question

I'm new to R and have started writing a medium-size project. Even though it will be distributed as part of an application, I've decided to make a package out of it to make the organisation neater.

How do I handle the fact that the DESCRIPTION file needs Version and Date fields, when I'm using version control? I wouldn't want to change that file with every git commit.

Is there a standard Makefile somewhere for this?

Further, I'm not completely clear on how I'd do this and still be able to use the package while developing.

Radioluminescence

You probably don't want to increment the package number for every change in the repo - there are currently no good tools to do this, and it has few advantages. – Undersurface

@hadley: No, but it would be nice to be able to find what version a user is using, for support purposes, and we also have a use-case that involves storing the package version as metadata in a data cleaning/processing suite (for scientific reproducibility). Perhaps some kind of pre/post-build hook that could update the DESCRIPTION and a small function to parse out the git revision.. Post-build hooks are mentioned at #32035651 , but I can't find any details anywhere else. – Celibate

Answer 1

If you use the devtools package you don't have to build and install your package after each edit - just use load_all() and the job is done in your working session, so you can test your changes (ideally with the testthat package).

I wrote an RPub about it: http://www.rpubs.com/geospacedman/lazydevtools

You still get the option to build a package source tarball for distribution.

Note that git doesn't promote a mechanism for automatically updating bits of files with every commit, like the $id$ thing in SVN. Linus himself said it was 'idiotic' and 'stupid':

http://www.gelato.unsw.edu.au/archives/git/0610/28891.html

Cystocele

Answer 2

If you are new to R I'd recommend using RStudio which is in my opinion the most advanced R-IDE. It provides both: package building as well as version control.

I wouldn't want to change that file with every git commit. ... Further, I'm not completely clear on how I'd do this and still be able to use the package while developing.

Well typically you would have one package installed for working with and your local Git repository for developing. When ever the development reaches the state for the next package release you would change the date and version in the DESCRIPTION file. Between two releases you can make as many stages, commits and pushes to your GIT as you want.

Fitted

What about someone else who clones the repo? They would have an invalid package, since the DESCRIPTION wouldn't correspond with the actual contents: the version in DESCRIPTION would not be the version of the code. – Radioluminescence

Maybe I'm looking for some kind of commit-hook to update the version with the git revision number – Radioluminescence

@Radioluminescence Either I'm very confused, or you are very confused, because your concerns about the version in the DESCRIPTION file make absolutely no sense to me. – Ruhl

@Radioluminescence Do you really want to build a new package for each Git-commit? Personally, I use to perform a couple of commits until the package reaches a state which I want to release. – Fitted

Answer 3

I don't change the DESCRIPTION for every commit, but I update Date and I put the current YYYYMMDD date in the version after the dash every time I actually build the package. It's kind of the nightly build keeping track of which night it was.

At the moment I have one package in a rather active development phase that is driven by the needs of several different coworkers. The date in minor version is convenient because I can easily ask coworkers "What date is the version you use? The sessionInfo () shows it."

Jewell