From Mark.Bravington at csiro.au  Sun Sep 11 02:48:12 2011
From: Mark.Bravington at csiro.au (Mark.Bravington at csiro.au)
Date: Sun, 11 Sep 2011 10:48:12 +1000
Subject: [Rd] Please explain your workflow from R code -> package -> R
 code	-> package
In-Reply-To: <CAErODj_mu8dOujVCJh14d-UbDw9qrq-9CC3MeeCSQ6d28-rJDg@mail.gmail.com>
References: <CAErODj_mu8dOujVCJh14d-UbDw9qrq-9CC3MeeCSQ6d28-rJDg@mail.gmail.com>
Message-ID: <3D59DF35E7CF3E42BA70C23BD5CBE6A85F59422557@exvic-mbx04.nexus.csiro.au>

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



[Rd] Please explain your workflow from R code -> package -> R code -> package
Mark.Bravington at csiro.au