From Mark.Bravington at csiro.au  Fri Dec 12 00:59:30 2008
From: Mark.Bravington at csiro.au (Mark.Bravington at csiro.au)
Date: Fri, 12 Dec 2008 10:59:30 +1100
Subject: [Rd] package development
In-Reply-To: <200812112304.mBBN4stJ008607@rocky.mayo.edu>
References: <200812112304.mBBN4stJ008607@rocky.mayo.edu>
Message-ID: <62C82B39B8A85E4B95A18F7F7B852F870FD7B1B5@exvic-mbx03.nexus.csiro.au>

Hi Terry

I suspect many people struggle with similar issues.

The new version of mvbutils contains a number of routines that facilitate creation & maintenance of a package, hopefully through its entire life-cycle: from "documenting your own stuff for personal use", through "giving out semi-documented code that your mates can use", through "getting it through all the CRAN hoops", through "maintaining & changing an already-installed-and-loaded package".

There is support for creating & editing functions (etc) in your own "development" package while it's already loaded, plus speedy on-the-fly updating of the installed version of the package. These in particular are things that R does not make easy by default (probably for good reasons). Plus: you don't have to learn Rd format if you don't want to-- the package-creator in mvbutils will generate Rd documentation for you based on plain-text documentation.

Use of these package-creation-maintenance routines does require some level of buy-in to 'mvbutils's view of how your working life in R should be organized... basically 'cd' and 'fixr'.  I don't reckon this should be much of a drama for most people, but there are so many different ways of working in R, so who knows?

I use these routines perpetually (maintaining about 6 packages), but as far as the rest of the universe goes, they are still alpha-releases. They are geared to the way I work, and so as yet might not do what others want; however, if there's demand and feasibility, I'm happy to try to incorporate other features. In particular, the documentation is incomplete at present, and I therefore haven't over-advertised the package-maintenance stuff until I get time to write a "how-to" article.

[I've had to release the package-maintenance stuff in a slightly undercooked state, because it is intimately bound to the guts of mvbutils, and it became necessary to roll out a maintenance release of mvbutils for other reasons.]

Let me know if this might be of further interest to you

Mark

-- 
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS

ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623

Terry Therneau wrote:
>   I'm making the move of the survival package from my own environment
> to, 
> and have stumbled into a vacuum.   The R Extensions manual has really
> nice instructions about how to lay out the directories, order the
> files, and 
> run tests for DISTRIBUTION of a product, but I can't find anything on
> how 
> to set up a reasonable DEVELOPMENT environment.
>    In my local world, I had the .c and .s files in a common
> directory, with 
> a Makefile that I had created, and the test suite in a subdirectory. 
> Debugging and development was quite nice.
> 	make
> 	cd test
> 	R
> 	attach("..")
> 		try something and perhaps it fails
> 	q()
> 	cd ..
> Fix and repeat. The Makefile took some time to create, but paid for
> itself a hundred times over.
> 
>   So, I've now rearranged everything into standard R order.  Then I
> did the only thing I could find
> 	R CMD INSTALL ~/myRlib  survival
> where "survival" is said directory.   This turns out to be not useful
> at all. The survival package is large, and I rather suspected that I
> would goof something up, and I did, resulting in the following message
> 
> 	Error in parse(n = -1, file = file) : unexpected end of input at
>         14450: }
>         14451:
> 
> It is not exactly obvious which of the 132 files in my R/ directory
> is the culprit here.
> 
>    In general:
> 1. The library is large, and recompiling/reparsing everything is very
> far from instantaneous.  It is not the edit/load cycle I desire.
> 
> 2. I take testing seriously: the test suite takes on the order of 15
> minutes to run on a fast machine.  I most certainly don't want to run
> it in the mid cycle. 
> 
>    Someone must have tackled this.  I'm hoping that there is some
> documentation that I have managed to overlook which discussess a good
> setup for this middle ground between concieving of a library and
> packaging it for delivery; the "build, test, make sure it acually
> works" part of development. 
> 
> 	Terry Therneau
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] package development
Mark.Bravington at csiro.au