[R] R package building

[Spencer Graves]

      My experience with building R packages has been extremely 
positive.  I've been using computers since I started writing Fortran in 
1963.  Before I started building R packages, debugging require excessive 
amounts of time.  Now, I write help file(s) first, including good test 
cases in the Examples section.  Examples that are more than I want to 
show readers go in a "dontshow" subsection.  After each change in a 
package, I rebuild the package. This way, if a change to function D 
breaks something in function A, I find out quickly -- unless I failed to 
test something important in Examples. 

      Currently, I write code for both Matlab and R.  I know of no such 
system for Matlab, and it is a problem for me.  I've tried testing 
Matlab from within Examples in an R help file, but I have not yet made 
that work. 

      Hope this helps. 
      Spencer Graves

Jay Emerson wrote:
> I agree with others that the packaging system is generally easy to
> use, and between the "Writing R Extensions" documentation and other
> scattered sources (including these lists) there shouldn't be many
> obstacles.  Using "package.skeleton()" is a great way to get started:
> I'd recommend just having one data object and one new function in the
> session for starters.  You can build up from there.
>
> I've only ran into time-consuming walls on more advanced, obscure
> issues.  For example: the "Suggests:" field in DESCRIPTION generated
> quite some debate back in 2005, but until I found that thread in the
> email lists I didn't understand the issue.  For completeness, I'll
> round out this discussion, hoping I'm correct.  In essence, I think
> the choice of the word "Suggests:" was intended for the package user,
> not for the developer.  The user isn't required to have a suggested
> package in order to load and use the desired package.  But the
> developer is required (in the R CMD check) to have the suggested
> package in order to avoid warnings or fails.  This does, actually,
> make sense, because we assume a developer would want/need to check
> features that involve the suggested package.  In a few isolated cases
> (I think I had one of them), this caused a problem, where a desired
> suggested package isn't distributed by CRAN on all platforms, so I
> would risk getting into trouble with R CMD check on the platform
> without the suggested package.  But this is pretty obscure, and the
> issue was obviously well-debated in the past.  The addition of a line
> or two about this in "Writing R Extensions" would be friendly (the
> current content is correct and minimal sufficient I believe).  Maybe I
> should draft this and submit it to the group.
>
> Secondly, I would advice a newbie to the packaging system to avoid S4
> at first.  Ultimately, I think it's pretty cool.  But, for example,
> documentation on proper documentation (to handle the man pages
> correctly) has puzzled me, and even though I can create a package with
> S4 that passes R CMD check cleanly, I'm not convinced I've got it
> quite right.  If someone has recently created more documentation or a
> 'white pages' on this, please do spread the word.
>
> Thanks to all who have -- and continue -- to work on the system!
>
> Jay
>
>   
>> Subject: [R] R package building
>>
>> In a few days I'll give a talk on R package development and my
>> personal experience, at the 3rd Free / Libre / Open Source Software
>> (FLOSS) Conference which will take place on May 27th & 28th 2008, in
>> the National Technical University of Athens, in Greece.
>>
>> I would appreciate if you could share
>> your thoughts with me; What are today's obstacles on R package
>> building, according to your
>> opinion and personal experience.
>>
>> Thanks,
>> --
>> Angelos I. Markos
>> Scientific Associate, Dpt of Exact Sciences, TEI of Thessaloniki, GR
>> "I'm not an outlier; I just haven't found my distribution yet"
>>     
>
>
>
>