The easiest way to start a package is to create a project in RStudio. From the menus choose

• New Project
• New Directory
• R Package

Be sure the "Create git repository" box is checked.

devtools helps set up some useful things. My favorites include

library(devtools)
use_mit_license()     # Or one of the other license choices
use_build_ignore()    # Create folder of things NOT in the package
use_github_links()    # Let people know about your github repo.
use_readme_rmd()      # Create README for Github using Rmd
use_data_raw()        # Folder of raw materials (including scripts) for data sets
use_news_md()         # Maintain your news with sensible syntax
use_testthat()        # Prepare for unit testing

Commit the files in the stub of your package.

• You don't have to commit hello.R and hello.Rd, they will be deleted soon anyway.

• But you need some committed files so we can establish the connection to Github.

1. Create new repository in Github
   • Do NOT have Github add any files.

2. Get "Clone or Download" string from Github

3. At the command line (use Terminal in rstudio)

git remote add origin <clone-or-download-string>
git remote -v              # check status
git push -u origin master  # link local master branch to Github

1. In R: use_github_links()

2. Go to Github and confirm that it worked.

• Setup personal tokens at [https://github.com/settings/tokens]

• Then

use_github(
  auth_token = <get this from Github>, 
  protocol = <"ssh" or "http">) 

This will create the repo on Github and link it to your local repo.

More details at [https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/]

• Create a stub using use_readme_rmd().
• Installation instructions will be included in the stub if you use use_github_links().
• Describe your package, provide some examples.

Issue tracking in Github is a great way to monitor progress on your package (and for others to provide bug reports if you make your package public).

If you refer to issues in your commit messages, comments will be added to Github.

1. Put code for your function in the R/ folder.

2. Document with roxygen2 (details in a moment)

   • Add Roxygen: list(markdown = TRUE) to your DESCRIPTION file so you can use Markdown short cuts when creating documentation.

3. If you use other packages:

   1. Use :: to qualify any external functions.
   2. Add external package to Imports: section of DESCRIPTION.
   3. Add `#' @importFrom package function.

Basic outline (for function):

#' Title for Documentation File
#' 
#' One paragraph description of things documented.
#' 
#' @param bar What kind of thing bar is and what it does.
#' @export
#' @examples
#' # Example code goes here

foo <- 
  function(bar) { }

• A number of other @ commands are available in roxygen2.

• Be sure to turn on roxygen tools in RStudio's build configuration options.

1. In R: use_data_raw() creates an ignored folder called data-raw/. Put the raw ingredients (csv, Excel, etc.) into this folder.

2. Create an R script in data-raw/ that reads in the raw data file, does any post-processing you need, and calls

use_data(<name of data object>, overwrite = TRUE)

1. Create an R script in R/ to document your data set.

#' @docType data
#' @name SomeData
#' @usage data(SomeData)
#' @format  A data.frame with ?? observations on the following ?? variables.
#'   * `var1` description for var1.
#'   * `var2` description for var2.
 
"SomeData"  # Trick to get documentation file named nicely.

Yes, you should be doing this!

(No, it isn't that hard).

1. use_testthat() sets things up.

2. Add R scripts in tests/testthat/ to do the testing.

context("Description of tests in this file")

test_that("Description of a sub-category of tests.", {
  # Build objects to be tested here
  object1 <- log(5, base = 10)
  object2 <- log10(5)
  expect_equivalent(object1, object2)
  expect_error(log(-2))
  expect_warning(1:3 + 1:2)
})

1. use_news_md() will create a stub for you.

2. As you make changes to the package, keep track of them in NEWS.md.

3. If you forget, look through your informative github commit messages as a reminder.

Vignettes are free form documentation that typically describe how to use the package (but they could include any information you like).

Easiest way to make them is with R Markdown:

1. use_vignette(<filename>) will create a stub vignette for you in vignettes/.

2. Edit the R Markdown file to create your vignette.

3. Don't forget to edit the boiler plate things like "Vignette Title".

Even in a private repository, vignettes can be useful.

CRAN provides a (large) number of checks of your package to make sure it is up to snuff:

• Everything in the package is documented (no check on quality of documentation).
• DESCRIPTION file has information it needs (in the proper format).
• NAMESPACE file includes what it needs.
• Code in examples and vignettes runs without errors.
• etc, etc, etc

It is good to run these checks even if your package is not heading to CRAN.

• devtools::build_win() will send your package to Win Builder, where it will be built. You will receive an email with links to the results of building and checking the package there.

• devtools::release() will walk you through the process of getting your package onto CRAN, reminding you to take care of all sorts of things along the way.

See Hadley Wickham's online book: R Packages at http://r-pkgs.had.co.nz/