Hi-- I guess I'm a bit late to the party. I enjoyed this thread immensely, and it helped me discover roxygen2, in what I predict to be the beginning of a beautiful friendship.
I wrote a couple of wrappers over the last few days which are making my workflow easier. I code on a computer but run my computations on several different boxes, meaning that I need a simple way (ideally one-liner) to deploy the code on each box. So I have a couple of wrapper functions, which I am happy to share with you. 1) RPush: this bash function roxygenizes, commits and pushes a package to a git repo. It assumes that your packages are all in a folder, the path to which is given by the environment variable $RPACK. For example $RPACK/Package1 and $RPACK/Package2.) function RPush { cd $RPACK/$1 R --quiet --vanilla --slave <<EOF suppressMessages(library(roxygen2)) roxygenize("./") EOF git add ./ git commit -am "$2" git push cd - > /dev/null } The syntax is RPush <package name> 'commit message' 2) GitInstall is an R function somewhat inspired by Hadley Wickham's Intall_Github, except that it is not bound to Github and can (I think) be used with any git server. GitInstall <- function( repo, branch = "HEAD", remote="git@yougitserver:yourrepo" ) { repo <- as.character(substitute(repo)) tartf <- tempfile() pkgtd <- tempfile() dir.create(pkgtd) on.exit(unlink(c(tartf, pkgtd))) system( paste( "git archive --format=tar --remote=", remote, repo, " ", branch, "> ", tartf, sep="" )) message("Attempting to install ", repo, " from ", remote, ".") system(paste( "tar -xf", tartf, "-C", pkgtd )) install.packages(pkgtd, repo=NULL, type="source") } You can then wrap it in a bash function such as function RInstall { sudo R --quiet --slave <<EOF Package1::GitInstall($1) EOF } (where it is assumed that you put the GitInstall function in Package1) So that to update a package and deploy it to a remote machine you just need to type: - on the local machine: RPush Package1 'commit message' - on the remote machine: RInstall Package1 I don't think it gets much lazier than that! Hope it helps, though I am sure this code is not super clean and may break for other people.. Timothee On Sun, Sep 11, 2011 at 1:48 AM, <mark.braving...@csiro.au> wrote: > I create & maintain all my packages using the 'mvbutils' package. > Documentation in plain-text format (not Rd) is stored along with each > function definition--- so when you edit your function, its doco is right > there too, and it looks like proper documentation, not code-comments or > quasi-Latex. The entire package source tree, including the Rd files, is > created automatically by the 'preinstall' function, after which you can then > R-BUILD the package as usual. However, with 'mvbutils' you only need R-BUILD > when you want a distribution version for others. Normal maintenance doesn't > require R-BUILD; you can add/remove/edit functions, documentation, and data > to the package on-the-fly while it is loaded, with no need to > unload/uninstall/rebuild/reload. > > It works with compiled code, too. My own way of working with compiled code is > a bit different to most other people's, but colleagues who use more > traditional routes have also successfully used 'mvbutils' to build and > maintain their packages. > > In the spirit of several other replies-- I spent months developing this stuff > and getting it to run smoothly, precisely because I'm lazy and have a limited > memory... > > HTH (though whether "yet another approach is..." will actually help you, I'm > not sure) > > Mark > > > Mark Bravington > CSIRO CMIS > Marine Lab > Hobart > Australia > ________________________________________ > From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf > Of Paul Johnson [pauljoh...@gmail.com] > Sent: 10 September 2011 02:38 > To: r-de...@stat.math.ethz.ch > Subject: [Rd] Please explain your workflow from R code -> package -> R code > -> package > > Hi, > > I'm asking another one of those questions that would be obvious if I > could watch your work while you do it. > > I'm having trouble understanding the workflow of code and package maintenance. > > Stage 1. Make some R functions in a folder. This is in a Subversion repo > > R/trunk/myproject > > Stage 2. Make a package: > > After the package.skeleton, and R check, I have a new folder with the > project in it, > > R/trunk/myproject/mypackage > DESCRIPTION > man > R > > I to into the man folder and manually edit the Rd files. I don't > change anything in the R folder because I think it is OK so far. > > And eventually I end up with a tarball mypackage_1.0.tar.gz. > > Stage 3. How to make the round trip? I add more R code, and > re-generate a package. > > package.skeleton obliterates the help files I've already edited. > > So keeping the R code in sync with the documentation appears to be a hassle. > > In other languages, I've seen to write the documentation inside the > code files and then post-process to make the documentation. Is there > a similar thing for R, to unify the R code development and > documentation/package-making process? > > pj > > -- > Paul E. Johnson > Professor, Political Science > 1541 Lilac Lane, Room 504 > University of Kansas > > ______________________________________________ > 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