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"
______________________________________________
R-help@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.
