Reputation: 7560
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.
Upvotes: 9
Views: 845
Reputation: 14093
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."
Upvotes: 2
Reputation: 94277
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
Upvotes: 5
Reputation: 7123
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.
Upvotes: 4