In Goodgolden/LDTM: Longitudinal Dirichlet Tree Multinomial Model

knitr::opts_chunk$set(echo = TRUE)

# install.packages(c("devtools", 
#                    "roxygen2", 
#                    "testthat", 
#                    "usethis", 
#                    "knitr"))
library(tidyverse)
library(testthat)
library(usethis)
library(devtools)

packageVersion("devtools")
## to create a package
# create_package("~/Desktop/bios7732/bios7732_package/LDTM")
use_mit_license()

## look for R home directory
R.home()
## look at the files in the same directory
here::here() %>%
  list.files()
# list.dirs()
# here::here() %>%
#   list.dirs(full.names = FALSE,
#             recursive = TRUE)

RStudio has special handling for packages and you should now see a Build tab in the same pane as Environment and History.

In the file browser, go to More > Show Hidden Files to toggle the visibility of hidden files (a.k.a. “dotfiles”). A select few are visible all the time, but sometimes you want to see them all.

.Rbuildignore lists files that we need to have around but that should not be included when building the R package from source.
.Rproj.user, if you have it, is a directory used internally by RStudio.
.gitignore anticipates Git usage and ignores some standard, behind-the-scenes files created by R and RStudio. Even if you do not plan to use Git, this is harmless.
DESCRIPTION provides metadata about your package. We edit this shortly.
NAMESPACE declares the functions your package exports for external use and the external functions your package imports from other packages. At this point, it is empty, except for a comment declaring that this is a file we will not edit by hand.
The R/ directory is the “business end” of your package. It will soon contain .R files with function definitions.
package.Rproj is the file that makes this directory an RStudio Project. Even if you don’t use RStudio, this file is harmless. Or you can suppress its creation with create_package(..., rstudio = FALSE).

use_git()

## example for a function
(x <- "alfa,bravo,charlie,delta")
strsplit(x, split = ",")

## This makes total sense in light of R’s 
## fundamental tendency towards vectorization. 
## But sometimes it’s still a bit of a bummer
str(strsplit(x, split = ","))

## The second, safer solution is the basis 
## for the inaugural function
strsplit1 <- function(x, split) {
  strsplit(x, split = split)[[1]]
}

Packages and scripts use different mechanisms to declare their dependency on other packages and to store example or test code.

use_r("01_tree")
use_r("02_likelihood")
use_r("03_dirichlet")
use_r("data")
use_test("01_tree")
use_test("02_likelihood")
use_test("03_dirichlet")


use_package("tidyverse", type = "depends")
use_package("purrr")
use_package("dplyr")
use_package("tidyr")
use_package("readr")
use_package("purrr")
use_package("tibble")
use_package("stringr")
use_package("forcats")
use_package("matrixcalc")

If this were a regular R script, we might use RStudio to send the function definition to the R Console and define strsplit1() in the global environment. Or maybe we’d call source("R/strsplit1.R").

load_all()
exists("Ytree",
       # where = globalenv(), 
       inherits = FALSE)
#> [1] FALSE

# ?exists Environment Access
env <- environment(Ytree)
exists("Btree", 
       where = env,
       # where = globalenv(), 
       inherits = FALSE)

This may seem silly to check, after such a small addition, but it’s good to establish the habit of checking this often.

check()

2.10 Edit DESCRIPTION

Use Ctrl + . in RStudio and start typing “DESCRIPTION” to activate a helper that makes it easy to open a file for editing.

In addition to a filename, your hint can be a function name.

This is very handy once a package has lots of files.

2.12 document()

document()
check()

The export directive in NAMESPACE is what makes a function available to a user after attaching via library.

Just as it is entirely possible to author .Rd files "by hand", you can manage NAMESPACE explicitly yourself.

install()
library(devtools)
load_all()

Note also that your package’s documentation won’t be properly wired up until it has been formally built and installed. This polishes off niceties like the links between help files and the creation of a package index.

RStudio exposes similar functionality in the Build menu and in the Build pane via Install and Restart.

library(LDTM)
use_testthat()
use_test("04_toy_example")

load_all()
# test_that("strsplit1() splits a string", {
#   expect_equal(strsplit1("a,b,c", split = ","), c("a", "b", "c"))
# })

Cmd + Shift + T (macOS) for test

It is a good idea to use the covr package to track what proportion of your package’s source code is exercised by the tests.

install.packages("covr")
library("covr")

report()
test()

# rename_files("treeY", "01_tree_structure")
## only for initiation
# use_github()

use_github() is a helper that we recommend for the long-term. We won’t demonstrate it here because it requires some credential setup on your end. We also don’t want to tear down and rebuild the public package every time we build this book.
set up the GitHub repo first! It sounds counter-intuitive, but the easiest way to get your work onto GitHub is to initiate there, then use RStudio to start working in a synced local copy. This approach is described in Happy Git’s workflows New project, GitHub first and Existing project, GitHub first.
command line Git can always be used to add a remote repository post hoc. This is described in the Happy Git workflow Existing project, GitHub last.

# use_readme_rmd()
build_readme()

usethis::use_data(toy_data0,
                  toy_data1, 
                  Design,
                  beta,
                  data_dtm,
                  internal = TRUE,
                  overwrite = TRUE)

usethis::use_git_remote("origin", 
                        url = NULL, 
                        overwrite = TRUE)

check()
load_all()