[R] Writing R packages in an easier way?

[Spencer Graves]

Dear Dr. Wolf:


       I understand your concern that the mechanics of writing an R 
package can be difficult.  It was hard for me when I started.


       I came to embrace it, because I actually got more done in less 
time doing so.  In my previous experience, as code I wrote got more 
complicated, it became more difficult to find bugs.  Then I started 
writing R packages, beginning by writing the documentation including 
examples that became unit tests 
(http://en.wikipedia.org/wiki/Unit_testing).  Then I wrote code to the 
test.  For example, I would first write function A.  Then I write B that 
calls A.  Then I write C that also uses A.  In the process of writing C, 
I modify A.  When I run "R CMD check", I learn that my change to A broke 
B.  I learn that instantly.  Without the R package discipline, it could 
be 6 months before I learned that I had a bug.  Then finding and fixing 
it was very difficult and time consuming.  Now, whenever I stumble over 
a new bug, I add it to my tests in the "examples" on the help page.  
People tell me I shouldn't put too much in the "examples", because the 
complicated examples can confuse users.  Fortunately, with "\dontshow", 
not all "examples" need to be shown to the users of the help page.


       By using the R package development process, I get more 
trustworthy software -- fewer bugs -- with less time, work, blood, sweat 
and tears.  The savings comes from less time spent debugging.  Moreover, 
the resulting software is generally better designed, because the process 
of writing the standard help page with the standard parts helps me think 
through what each function should do and how they all should work 
together.  I save so much debugging time that I essentially get the 
documentation for free.  This makes it much easier to share my code with 
others -- and to revisit code I wrote previously but had forgotten many 
details.


       I started writing Fortran in 1963, and I had many bad software 
development habits.  I had read a lot about software productivity and 
the virtues various software productivity practices.  It was only when I 
started writing R packages that I began to actually use those 
recommended practices productively.


       I've never read the entire "Writing R Extensions" manual, though 
I have used it repeatedly as a reference.  Fortunately, there are 
simpler introductions to R package development.  Have you checked the 
"contributed" page on CRAN for the word "package"?  I just found 9 
matches, including 4 documents on creating R packages, two in English, 
one in French, and one in Italian.  Leider, kein Deutsch.


       Hope this helps.
       Spencer


On 2/11/2011 3:03 AM, Barry Rowlingson wrote:
> On Fri, Feb 11, 2011 at 7:52 AM, Dr. Michael Wolf<m-wolf at muenster.de>  wrote:
>> Dear R colleagues,
>>
>> is there an easier way to write R packages for the own use - without RTools
>> and TeX?
>   There are simpler ways of maintaining R source code than building
> packages. I bashed out a quick way of keeping code in directories as
> source and reading in on demand. All you need is two functions:
>
> import<- function(dir){
>    e = attach(NULL,name=dir)
>    assign("__path__",dir,envir=e)
>    reload(e)
>    invisible(e)
> }
>
> reload<- function(e){
>    path = get("__path__",e)
>    files = list.files(path,".R$",full.names=TRUE,recursive=TRUE,ignore.case=TRUE)
>    for(f in files){
>      sys.source(f,envir=e)
>    }
> }
>
>   Now put the source code in some folder/directory somewhere. You can
> even make subdirs if you wish to organise it that way.
>
>   I've got some .R files in "lib1". I do;
>
>   >  import("lib1")
>
>   and that runs 'source' on all the .R files in there and loads them
> into position 2 on the search list. ls(pos=2) shows them.
>
>   If you edit the source code, just do reload(2) (assuming it hasn't
> moved because you've loaded another package) and your stuff will be
> updated. It just sources everything again. Do detach(2) to get rid of
> it.
>
>   If you want to distribute your code in "source" format, just make a
> zip or tar of the folder with the code in, and make sure your users
> have the import and reload functions (I should probably put them in a
> package one day...).
>
>   To distribute in 'binary' format, do an import, and then save as .RData:
>
>   >  save(list=ls(pos=2),file="lib1.RData", envir=as.environment(2)) #
> not well tested....
>
> Then your users just need to attach("lib1.RData") to get your functions.
>
>   Now this scheme could get more complex - for example it doesn't deal
> with C or Fortran code, or documentation, or tests, or examples, or
> version numbering. Adding any of those would be pointless - if you
> want any of that either use packages and learn to write R docs
> (roxygen helps) or add it to my code yourself. You'll end up
> rebuilding the R package system anyway.
>
>   Hope this helps. Doubtless someone else will come up with a simple
> way to build proper packages without all the bondage and discipline
> that annoys you.
>
> Barry
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>