Please explain your workflow from R code -> package -> R code -> package
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 at 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.Bravington at 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-bounces at r-project.org [r-devel-bounces at r-project.org] On Behalf Of Paul Johnson [pauljohn32 at gmail.com] Sent: 10 September 2011 02:38 To: r-devel at 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 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