I have several custom functions that I use frequently in R. Rather than souce this file (or parts thereof) in each script, is there some way to add this to a base R file such that they are always available when I use R?
+11
A:
Yes, create a package. There are numerous tutorials as well as the Writing R Extensions manual that came with your copy of R.
It may seem like too much work at first, but you will probably be glad that you did this in the longer run.
PS And you can then load that package from ~/.Rprofile. For really short code, you can also define it there.
Dirk Eddelbuettel
2010-07-08 18:33:20
A package is definitely the right answer.
Shane
2010-07-08 20:08:00
Just compiled my first package. Didn't realize how easy it was. Thanks Dirk!
Maiasaura
2010-07-08 21:00:59
Congrats -- Nicely done!
Dirk Eddelbuettel
2010-07-08 21:03:53
Glad that ended up as the accepted answer. Packages are easy and provide so many benefits! (e.g. http://stackoverflow.com/questions/2284446/organizing-r-source-code/2284486#2284486)
Shane
2010-07-08 21:30:48
nice, I'm going to try this!
apeescape
2010-07-08 23:38:01
Agreed- R makes creating packages dead simple. One of the easiest languages to extend in my experience.
Sharpie
2010-07-10 04:53:21
Dirk, that link does not work, because R-exts.html is written with a small "e" . The correct link should be: http://cran.r-project.org/doc/manuals/R-exts.html , thx for editing in advance. Nice answer and question – should be correctly archived :)
ran2
2010-07-10 12:15:21
Thanks -- fixed!
Dirk Eddelbuettel
2010-07-10 13:44:25
+3
A:
A package may be overkill for a for a few useful functions. I'd argue there's nothing wrong with explicitly source()ing them as you need them - at least it is explicit so that if you email someone your code, you won't forget to include those other scripts.
hadley
2010-07-10 11:18:11
A:
You could also look at the 'mvbutils' package: it lets you set up a hierarchical set of "tasks" (folders with workspace ".RData" files in them) such that you can always see what's in the ancestral tasks (ie the ancestors are in the search() path). So you can put your custom functions in the "starting task" where you always start R; and then you change to vwhatever project-specific task you require, so you can avoid cluttered workspaces, but you'll still be able to use (and edit) your custom functions because the starting task is always ancestral. Objects (including functions) get stored in ".RData" files and are thus loaded/saved automatically, but there are separate text-backup facilities for functions.
There are lots of different ways of working in R, and no "one-size-fits-all" best solution. It's also not easy to find an overview! Speaking just for myself:
I'm not a fan of having to 'source' everything in every time; for one thing, it simply doesn't work with big data sets and/or results of model runs.
I think packages are hard to create and maintain; there is a really significant overhead. After the first 5 packages you write, it does get a bit easier provided you do it on at least a weekly basis so you don't forget how, but really...
In fact, 'mvbutils' also has a bunch of tools for facilitating the creation and (especially) maintenance of packages, designed to interface smoothly with the task-hierarchy system. I use & edit my own packages all the time (including editing mvbutils itself); but if it wasn't for the tools in 'mvbutils', I'd be grinding my teeth in frustration most days of the week.
Mark Bravington
2010-07-16 05:34:24