Appveyor We Encountered an Internal Error Please Try Again

mayo 14, 2022 Publicar un comentario

Introduction

One of the fundamental roles of a statistician is to create methods to analyze data. This typically involves 4 components: developing the theory, translating the equations to computer lawmaking, a simulation study and a real data analysis. While these are enough to get published, it is unlikely your method will be used by others without a primal fifth component: a software package. A package is a collection of reusable functions, the documentation that describes how to use them, tests and sample data. They provide a structured mode to organize, use and distribute code to others and/or your future cocky. The objective of this workshop is to learn how to develop an R package. In addition to creating an R package from scratch, you volition larn how to make information technology robust beyond platforms and future changes using continuous integration and unit of measurement testing. This workshop assumes familiarity with R, RStudio, writing functions, installing packages, loading libraries and requires a GitHub account. This will exist an interactive workshop.

Pre-workshop set up-upwardly

You must bring your own laptop. It is vital that yous attempt to ready your system in advance. Y'all cannot show up at the workshop with no preparation and go on upward!

R (version ≥ 3.6.0)
RStudio (version ≥ 1.ii.1335). This is a powerful graphical user interface (GUI) which makes the package creation process much easier.
Git. I strongly recommend reading these setup instructions past Jenny Bryan for Mac/Windows/Linux and the Troubleshooting section.
Please read Chapter ane: Why Git? Why GitHub? to understand the big picture and motivation for using Git and Github.
Sign upwardly for a GitHub business relationship. Nosotros volition employ GitHub to host the source files of our R package. I as well recommend reading Jenny Bryan'south communication on carefully choosing a username.
GitKraken. This is a GUI for Git which makes information technology much easier to dive into version control without the command line. GitKraken is to Git what RStudio is to R. This is optional merely highly recommended, particularly for new Git users. You lot are gratuitous to use the GUI of your choice or but the command line. In this workshop I will be using GitKraken.
Complete Section three of this tutorial.
Run the following commands in R:

                          install.packages("pacman")              # this command checks if yous have the packages already installed,                            # then installs the missing packages, and so loads the libraries              pacman::              p_load(knitr, rmarkdown, devtools, roxygen2, usethis)              # place yourself to Git with the usethis package              # employ the verbal same username and email associated              # with your GitHub account              usethis::              use_git_config(user.name =              "gauss",              user.email =              "gauss@normal.org")

Git and GitHub

Introduction

This department walks y'all through the process of creating a GitHub repository (abbreviated as repo), creating a local copy of the repo (i.e. on your laptop), making some changes locally and updating your changes on the remote (aka GitHub repo). Information technology assumes that you lot have successfully completed the requirements outlined in Section 2. The following effigy summarizes some key terminology that nosotros will make use of in this section:

Annotations

For each stride, I accept provided screenshots annotated with crimson rectangles, circles and arrows. You can click on each paradigm to enlarge information technology. The following table describes what each of the annotations represent.

Annotation	Clarification
	Enter text or fill in the blank
	Click on the circled push
	Have note of. No action is required.

Stride i: Create a remote repo

Nosotros first create a GitHub repo. Head over to https://github.com and login. Then click on new repository:

Give information technology a proper noun. It can be anything you want (just choice a name that will remind you that this repository contains the source files of your R packet). In the screenshots beneath I used rpkg throughout. Click on Create repository:

Copy the link of your newly created repo to your clipboard:

Stride 2: New `RStudio` Project via `git clone`

Create a local copy of the remote repo using RStudio projects:

Click on Version Control:

Click on Git. Note that if you get an error or y'all don't see this choice, this likely means that your RStudio doesn't know where to find your local Git installation. Please see Chapter 13: Find Git from RStudio for troubleshooting this.

Paste the link to your remote repo in the Repository URL box, proper noun the folder that will contain your R bundle files, and browse to where you want the binder to be saved in your filesystem. Click on Create Projection:

Your RStudio window should open a new project in the specfied directory. Take notation of the post-obit points annotated in the screenshot beneath:

The Git tab allows you to use Git and push to GitHub inside RStudio. Y'all volition meet whatsoever changes that have been made to your files since the last commit here. I accept found the RStudio interface to Git to exist inadequate and irksome. I just want you to be aware of this functionality. I only look at this tab to quickly run across if there were any changes, only do all my version controlling and interfacing with GitHub using GitKraken.
Shows the path of your working directory, which is set up to the root of your RStudio project by default. You can always click on the arrow to return to the working directory.
Indicates the name of your Rstudio project. It's also a dropdown menu for other recently opened RStudio projects.
Filesystem viewer of your working directory. You should run into a .gitignore file and the RStudio project file. These were automatically added by RStudio when y'all created a new project from a GitHub repo.
A dropdown bill of fare with extended Git functionalities.

Stride 3: `add` and `commit` your changes

The post-obit figure shows the commands needed for a basic version controlled workflow. Refer dorsum to this figure in one case y'all complete Step 3 then once again when y'all complete Stride iv (it should make a fiddling more sense).

Have you lot ever versioned a file by adding your initials or the date? That is effectively a commit, albeit only for a single file: it is a version that is meaning to you and that y'all might desire to inspect or revert to later on (Bryan, STAT545TAs, and Hester 2019). The commit command is used to save your changes to the local repository. From the Git tab, click on Commit:

Note that you have to explicitly tell Git which changes y'all want to include in a commit before running the git commit command. This means that a file won't be automatically included in the next commit only considering information technology was changed. Instead, you demand to utilise the git add control to mark the desired changes for inclusion. Instead of typing git add in the terminal, y'all tin can simply click the boxes next to the files you want to add (this is also referred to as staging a file). The lines 1 to 4 highlighted in light-green refer to the contents of the .gitignore file and the green highlight indicates they are beingness added to the file (red highlight indicates removal of a line):

Every time you brand a commit you must also write a curt commit bulletin. Ideally, this conveys the motivation for the modify. Remember, the diff will prove the content. When you revisit a projection after a interruption or need to digest recent changes fabricated past a colleague, looking at the history, by reading commit letters and skimming through diffs, is an extremely efficient mode to become upward to speed (Bryan, STAT545TAs, and Hester 2019). Enter a commit message and click on the Commit button:

If everything worked, y'all should come across the following screen with the commit message and the files that were added:

Pace 4: `push` your local commits

The push control is used to publish new local commits on a remote server (the remote repo y'all created in Step 1):

Enter your username:

and your password:

Note the following:

The URL of the remote repo.
The name of the local co-operative called principal. (We'll talk most branches later on).
The name of the remote branch likewise called master. master -> master indicates that you lot have pushed the commit from the local master branch to the remote master branch.
The command you tin enter in the terminal instead of using the RStudio interface to push your commit to the remote.

Head over to your remote GitHub repo and have note of the following:

The newly added files.
The commit message.
You are currently viewing the contents of the principal branch.
The unique ID of the commit. A Git commit ID is a SHA-1 hash of every important thing virtually the commit. Clicking on it will allow you to see the deviation (aka diff) between the previous commit.
The number of commits (aka snapshots of the repo).
The number of branches.

Step 5: Open the repo with `GitKraken`

Link your GitHub account to GitKraken; you lot will be prompted for this when opening the GitKraken application for the showtime fourth dimension. Open the local repo created in Step 2:

The following screenshot shows the local repo in the GitKraken GUI. Note the following (which has like attributes to the online GitHub repo):

The newly added files.
The commit message.
You are currently viewing the contents of the master co-operative.
The unique ID of the commit. A Git commit ID is a SHA-1 hash of every important affair almost the commit. Clicking on information technology will allow you to see the difference (aka diff) between the previous commit.
The branches available locally.
The branches available on the remote.

Discussion

Hopefully you were able to successfully complete all the steps in this Section. The main takeaway is to be able to add together, commit, and button your local commits to the remote repo. It'southward completely normal if you still have very little understanding of what merely happened. I volition clarify during the workshop. The point was for you to take a first stab at using version command and come up to the workshop as prepared as possible.

Edifice an `R` package

This section runs through the evolution of a small toy package. It's meant to illustrate the nigh important components of an R parcel. We will then provide a detailed handling of the key components in the adjacent sections.

Package Structure

A packet is a convention for organizing files into directories. Effigy four.1 shows the 7 nigh common parts of an R bundle.

Clarification file (required): contains key metadata for the bundle that is used by repositories like CRAN and by R itself. This file contains the bundle name, the version number, the writer and maintainer contact information, the license data, as well equally any dependencies on other packages.
NAMESPACE file (required): specifies the interface to the package that is presented to the user. This is washed via a series of export() statements, which indicate which functions in the packet are exported to the user. Functions that are not exported cannot exist called direct by the user (or they must use :::). In addition to exports, the NAMESPACE file also specifies what functions or packages are imported past the packet. If your package depends on functions from another package, you lot must import them via the NAMESPACE file.
R sub-directory (required): The R sub-directory contains all of your R code, either in a single file, or in multiple files. For larger packages information technology'due south usually best to dissever code up into multiple files that logically grouping functions together. The names of the R code files do non thing, just by and large it's not a good thought to have spaces in the file names.
man sub-directory (required): contains the documentation files for all of the exported objects of a package. The roxygen2 package allows you to write the documentation directly into the R code files. Therefore, you volition likely accept footling interaction with the man directory as all of the files in there will be auto-generated past the roxygen2 packet from the R lawmaking files.
tests sub-directory: to shop tests that will alert y'all if your lawmaking breaks.
vignettes sub-directory: holds documents that teach your users how to solve real problems with your tools.
data sub-directory: allows yous to include data with your packet.

Getting Started

Nosotros volition rely heavily on the following packages to build our own package:

usethis (Wickham and Bryan 2018) for setup and creating the required files and folders
devtools (Wickham, Hester, and Chang 2018) to build, install and check our package
roxygen2 (Wickham, Danenberg, and Eugster 2018) to document our functions
rmarkdown (Xie, Allaire, and Grolemund 2022 ; Allaire et al. 2019) for creating package vignettes

Step 1: Cheque working directory

Ensure that your working directory is set to the root of the GitHub repo you created in Section 3. The following shows a plain text listing of the directory (at this phase, it should only contain two files):

                -- .gitignore -- rpkgs.Rproj

Pace 2: Add required `R` package files

Run the following commands in R from the root directory of your parcel:

                                  # creates description and namespace files                  usethis::                  use_description() usethis::                  use_namespace()                  # Create R directory                  base::                  dir.create("R")                  # creates Bundle-level documentation then yous can run ?nameofpackage                  usethis::                  use_package_doc()                  # created README.Rmd for Github landing folio                  # an .Rbuildignore file gets created                  usethis::                  use_readme_rmd()                  # creates license file                  usethis::                  use_mit_license("Sahir Bhatnagar")                  # creates news file                  usethis::                  use_news_md()                  # setup continuous integration via travis-ci                  usethis::                  use_travis()                  # sets up testing infrastructure                  usethis::                  use_testthat()

Your package directory should now have the following structure:

                -- .gitignore -- .Rbuildignore -- .travis.yml -- DESCRIPTION -- LICENSE -- LICENSE.md -- NAMESPACE -- NEWS.md -- R    |__rpkg-packet.R -- README.Rmd -- rpkg.Rproj -- tests    |__testthat    |__testthat.R

Step 3: Configure `RStudio` build options

Restart RStudio. You lot should at present see a Build tab:

Click on the .Rproj file:

Change the following options:

Step 4: Build and install

On the Build tab, click on Install and Restart or use Ctrl/Cmd + Shift + B:

This will install and load your package. At present enter the following commands:

                ?rpkg rpkg::                  pacman::                  p_functions(rpkg)

You volition notice that your package has a assist folio for the parcel by calling ?rpkg and as well has no functions (given by pacman::p_functions()):

In the man folder you will see a rpkg-packet.Rd file. This is an R documentation formatted file and is generated automatically by the roxygen2 bundle. We will talk more about documentation in the following sections.

Step 5: Fill in the blanks and commit changes

Exercise: Update the DESCRIPTION file and the README.Rmd file. Then rebuild the package. Add and commit your changes and push them to the remote repo. Check the commit history and the differences between the previous commit.

Step six: Add together a dataset

It'due south frequently useful to include data in a bundle. If you're releasing the bundle to a wide audition, it'due south a way to provide compelling employ cases for the packet'south functions. Before I first writing functions for my packages, I usually add together a toy dataset kickoff. Enter the following R code:

                                  # this will setup the folders needed for the data and raw-data                  usethis::                  use_data_raw()

The information-raw binder gets added to the .Rbuildignore so that it's non shipped with the package. This binder is used to store the raw data and the scripts used to parse information technology and create the terminal version of the dataset.

For this do, nosotros volition utilise a data set on ii-calendar week seizure counts for 59 epileptics (or you can employ your ain). Download the raw .csv file and salve information technology in the information-raw binder.

Create an R script called seizure-data.R and save it in the data-raw folder. This script will comprise the code used to clean the dataset and ouput the concluding cleaned version to exist shipped with the package. Enter the following lawmaking in the seizure-information.R script:

                                  # load required packages ----                  if                  (!                  require("pacman"))                  install.packages("pacman")  pacman::                  p_load(magrittr, dplyr, usethis, data.tabular array, here)                  # clean information ----                  epil <-                                    read.csv(here::                  here("data-raw","epil.csv")) DT <-                  epil                  %>%                                    equally.information.table DT.base of operations <-                  DT                  %>%                                                      distinct(subject,                  .keep_all =                  Truthful) DT.base of operations[,`                  :=                  `(period=                  0,y=base)] DT.epil <-                                    rbind(DT, DT.base of operations)                  setkey(DT.epil, subject, menses) DT.epil[,`                  :=                  `(mail service=                  as.numeric(period>                  0),                  tj=                  ifelse(catamenia==                  0,8,ii))] df_epil <-                                    as.data.frame(DT.epil)                  %>%                                    dplyr::                  select(y, trt, post, subject, tj)                  # write data in correct format to information folder ----                  usethis::                  use_data(df_epil,                  overwrite =                  True)

Practise: Source the seizure-information.R script. Audit the additions and then add and commit the changes.

Footstep 7: Certificate the dataset

Datasets must be documented. We usually certificate them in R/data.R. Enter the post-obit in a file chosen data.R and salve it in the R folder:

                                  #' Seizure Counts for Epileptics                  #'                  #' @description Thall and Vail (1990) give a data set on ii-week                                    #' seizure counts for 59 epileptics. The number of seizures was                                    #' recorded for a baseline catamenia of eight weeks, and so patients                                    #' were randomly assigned to a handling group or a command group.                                    #' Counts were then recorded for 4 successive two-week periods.                                    #' The subject'south age is the merely covariate.                  #'                  #' @format his information frame has 295 rows and the post-obit v columns:                  #' \describe{                  #'   \item{y}{the count for the 2-week period.}                  #'   \item{trt}{treatment, "placebo" or "progabide"}                  #'   \item{mail service}{post handling. 0 for no, one for aye}                  #'   \detail{field of study}{discipline id}                  #'   \item{tj}{time}                  #' }                  #' @source \url{https://cran.r-projection.org/packet=MASS}                  "df_epil"

You can likewise document multiple datasets in the same R file (run across here for an example). Refer to the Documentation section for more details on roxygen2 tags.

Practise: Re-build the package. Check out the help page for the df_epil dataset using ?df_epil. Inspect the additions and then add together and commit the changes.

Step eight: Add an `R` function

To brand our package really useful, we need to add an R office. I employ the following part for the purposes of illustration, which analyzes the data and outputs a summary of the results in the form of an HTML table. Save this function in R/fit_models:

                fit_models <-                                    function(formula, data) {    fit.glmm <-                  lme4::                  glmer(formula,                  data =                  information,                  family unit =                  "poisson",                  showtime =                  log(tj))      sjPlot::                  tab_model(fit.glmm)  }                  # example of how to utilize the role                  # fit_models(formula = y ~ trt*post + (i|subject field), information = df_epil)

Step nine: Certificate the `R` function

We over again make use of the roxygen2 parcel to document our R function. The sinew (Sidi 2018) packet creates a skeleton for us. Enter the post-obit commands in R to certificate the office:

                pacman::                  p_load(sinew) sinew::                  makeOxyFile("R/fit_models.R")

Exercise: Delete the R/fit_models.R file and rename R/oxy-fit_models.R to R/fit_models.R. Fill in the roxygen2 template (refer to the Department on documentation for more details). Re-build the package. Cheque out the assistance page for the fit_models function using ?fit_models. Inspect the additions so add and commit the changes. Push to the remote repo.

Step 10: Dependencies: What does your package need?

Come across complete references on DESCRIPTION and NAMESPACE.

It's the job of the Description to list the packages that your package needs to piece of work. R has a rich set of ways of describing potential dependencies. For example, the post-obit lines bespeak that my package needs both lme4 and sjPlot to work:

                Imports:     lme4,     sjPlot

Whereas, the lines beneath indicate that while my parcel can take advantage of lme4 and sjPlot, they're not required to make information technology work:

                Suggests:     lme4,     sjPlot

Both Imports and Suggests take a comma separated list of package names. I recommend putting ane bundle on each line, and keeping them in alphabetical order. That makes it easy to skim.

Imports and Suggests differ in their strength of dependency:

Imports: packages listed here must be present for your packet to work. In fact, whatsoever fourth dimension your parcel is installed, those packages volition, if not already present, exist installed on your computer (devtools::load_all() also checks that the packages are installed).

Calculation a bundle dependency in Imports ensures that it'll be installed. However, it does non hateful that information technology will be fastened along with your package (i.eastward., library(x)). The best practice is to explicitly refer to external functions using the syntax package::function(). This makes it very easy to identify which functions alive outside of your packet. This is specially useful when you lot read your lawmaking in the futurity.

Suggests: your package can apply these packages, but doesn't require them. Yous might apply suggested packages for case datasets, to run tests, build vignettes, or maybe in that location's only ane role that needs the package. Packages listed in Suggests are not automatically installed along with your package. This means that you demand to check if the parcel is available before using it (use requireNamespace(x, quietly = Truthful)). There are two bones scenarios:

                                  # You lot need the suggested packet for this role                                    my_fun <-                                    office(a, b) {                  if                  (!                  requireNamespace("pkg",                  quietly =                  True)) {                  finish("Package                                    \"                  pkg                  \"                                      needed for this function to work. Delight install it.",                  phone call. =                  False)   } }                  # There's a fallback method if the package isn't bachelor                  my_fun <-                                    function(a, b) {                  if                  (requireNamespace("pkg",                  quietly =                  TRUE)) {     pkg::                  f()   }                  else                  {                  g()   } }

The easiest way to add Imports and Suggests to your package is to use:

                usethis::                  use_package("lme4",                  type =                  "Imports") usethis::                  use_package("lme4",                  type =                  "Suggests")

This automatically puts them in the correct identify in your Clarification, and reminds you how to use them.

It's mutual for packages to be listed in Imports in DESCRIPTION, merely not in NAMESPACE. In fact, this is what Hadley recommends: listing the bundle in Clarification and then that it's installed, then always refer to it explicitly with pkg::fun(). The antipodal is not true. Every bundle mentioned in NAMESPACE must likewise be nowadays in the Imports or Depends fields.

Practise: Add together lme4 and sjPlot to the DESCRIPTION. Re-build the package. Check out the help page for the parcel using ?rpkg. Inspect the additions and and so add and commit the changes. Push to the remote repo.

Step xi: Check your package

R CMD cheque, executed in the final, is the gold standard for checking that an R package is in full working order. devtools::cheque() is a user-friendly way to run this without leaving your R session.

Exercise: Run devtools::check(). Ready the errors and rebuild the package. Add and commit your changes and push to remote repo.

Vignettes

You will likely desire to create a document that walks users through the basics of how to apply your package. You can do this through 2 formats:

Vignette: This document is bundled with your R package, and so it becomes locally available to a user once they install your package from CRAN. They will as well have it available if they install the packet from GitHub, as long every bit they use the build_vignettes = Truthful selection when running remotes::install_github.
README file: If you have your parcel on GitHub, this certificate will show up on the primary folio of the repository if there is a README.medico file in the top directory of the repository. For an example, visit https://github.com/geanders/countytimezones and scroll down. You'll see a list of all the files and subdirectories included in the packet repository and below that is the content in the packet's README.medico file, which gives a tutorial on using the package.

The README file is a useful way to requite GitHub users information about your package, but information technology will not be included in builds of the package or be bachelor through CRAN for packages that are posted there. Instead, if y'all want to create tutorials or overview documents that are included in a package build, you should do that by adding one or more than parcel vignettes. Vignettes are stored in a vignettes subdirectory within the package directory.

To add a vignette file, saved within this subdirectory (which will exist created if you do not already take it), use:

            usethis::              use_vignette(name =              "Introduction to my parcel")

Once you create a vignette with usethis::use_vignette, be sure to update the Vignette Index Entry in the vignette'south YAML (the lawmaking at the top of an R Markdown document). Replace Vignette Championship at that place with the bodily championship you utilize for the vignette.

Practice: Re-build the package. Audit the additions and so add together and commit the changes. Brand sure the vignette is able to exist compiled. Then push to the remote repo.

Continous Integration

The objectives of this department are:

Create an R packet that is tested and deployed on Travis
Create an R package that is tested and deployed on Appveyor

Continous integration (aka checking your packet after every commit) is a software development technique used to ensure that whatsoever changes to your code do not suspension the package's functionality. Travis is a continuous integration service, which ways that information technology runs automated testing code everytime you push to GitHub. For open up source projects, Travis provides fifty minutes of gratis computation on a Ubuntu server for every push. For an R package, the most useful code to run is devtools::check().

When it comes to R packages continuous integration means ensuring that your packet builds without any errors or warnings, and making sure that all of the tests that you've written for your packet are passing. Building your R bundle will protect you against some big errors, but the best way that you can ensure continuous integration will be useful to you is if you build robust and consummate tests for every office in your packet.

Travis and Appveyor

Travis volition exam your packet on Linux, and AppVeyor will test your packet on Windows. Both of these services are gratis for R packages that are built in public GitHub repositories. These continuous integration services volition run every time you button a new ready of commits for your package repository. Both services integrate nicely with GitHub so you can see in GitHub's pull request pages whether or not your package is building correctly.

Using Travis

To starting time using Travis:

Get to https://travis-ci.org and sign in with your GitHub account.
Ensure that you have run usethis::use_travis().
Clicking on your name in the upper right paw corner of the site will bring up a list of your public GitHub repositories with a switch next to each repo. If you turn the switch on then the next time you button to that repository Travis will expect for a .travis.yml file in the root of the repository, and it will run tests on your package accordingly.
Now add, commit, and push your changes to GitHub, which will trigger the offset build of your package on Travis. Become dorsum to https://travis-ci.org to sentry your package be built and tested at the same time! Y'all may desire to make some changes to your .travis.yml file, and you can come across all of the options bachelor in this guide.

One time your package has been built for the first fourth dimension you'll exist able to obtain a badge, which is simply a pocket-sized image generated by Travis which indicates whether you lot package is building properly and passing all of your tests. You should brandish this badge in the README.Rmd file of your packet'southward GitHub repository so that you and others tin monitor the build status of your package (you should see the code for the bluecoat appear in your console once you use usethis::use_travis()).

Using AppVeyor

To first using AppVeyor:

Go to https://world wide web.appveyor.com/ and sign in with your GitHub business relationship.
Ensure that y'all take run usethis::use_appveyor(). This control volition set a default appveyor.yml for your R package
After signing in click on Projects in the top navigation bar. If you have whatsoever GitHub repositories that apply AppVeyor y'all'll be able to see them here. To add together a new project click New Projection and find the GitHub repo that corresponds to the R parcel yous'd like to test on Windows. Click Add for AppVeyor to start tracking this repo.
Now add, commit, and push your changes to GitHub, which will trigger the first build of your bundle on AppVeyor.
Become back to https://world wide web.appveyor.com/ to meet the result of the build. You may desire to brand some changes to your appveyor.yml file, and yous can see all of the options available in the r-appveyor guide which is maintained by Kirill Müller.
Like Travis, AppVeyor also generates badges that you lot should add together to the README.Rmd file of your packet'south GitHub repository (you should see the code for the badge appear in your console once you use usethis::use_appveyor())

Exercise: Re-build the package. Inspect the additions and and then add and commit the changes. Then push to the remote repo.

Tests

Encounter complete reference.

What to test: Whenever you are tempted to type something into a impress argument or a debugger expression, write it as a test instead. — Martin Fowler

Testing is a vital part of packet development. Information technology ensures that your code does what yous want it to do. Testing, yet, adds an additional step to your evolution workflow. The goal of this section is to prove y'all how to brand this task easier and more constructive by doing formal automated testing using the testthat package.

The testthat package is designed to brand information technology easy to setup a bombardment of tests for your R packet. A nice introduction to the bundle can exist found in Hadley Wickham'southward article in the R Journal. Essentially, the package contains a suite of functions for testing function/expression output with the expected output. Add together the post-obit to tests/testthat/test-fit_models.R:

                          context("run fit_model with packaged dataset df_epil")              information("df_epil")  fit <-                            endeavor(fit_models(formula =              y              ~                            trt*post              +                            (i              |discipline),              data =              df_epil),              silent =              True)              test_that("no error in fitting fit_models for the epilepsy data", {              expect_false(inherits(fit,              "try-fault"))  })

And then run the post-obit commands in R:

                          # execute the test              devtools::              test()              # use lawmaking coverage              usethis::              use_coverage()              # bank check lawmaking coverage              devtools::              test_coverage()

Exercise: Re-build the package. Run devtools::cheque(). Fix whatsoever errors. Inspect the additions and and then add and commit the changes. Then button to the remote repo.

Another example

Practise: Document the post-obit function and write a test for it. Think about checking for a positive definite covariance matrix and create a function for this check.

              sim.expr.information <-                                role(n, n0, p, rho.0, rho.1){                # Initiate Simulation parameters                # n: total number of subjects                # n0: number of subjects with 10=0                # n1: number of subjects with X=1                # p: number of genes                # rho.0: rho between Z_i and Z_j when X=0                # rho.1: rho betwixt Z_i and Z_j when X=i                # Simulate factor expression values according to exposure X=0, X=1,                                # according to a centered multivariate normal distribution with                                # covariance betwixt Z_i and Z_j being rho^|i-j|                times =                                1                :p                # used for creating covariance matrix                H <-                                abs(outer(times, times,                "-"))   V0 <-                rho.0                ^H   V1 <-                rho.1                ^H                # rows are people, columns are genes                genes0 <-                MASS::                mvrnorm(north =                n0,                mu =                rep(0,p),                Sigma =                V0)   genes1 <-                MASS::                mvrnorm(n =                n1,                mu =                rep(0,p),                Sigma =                V1)   genes <-                                rbind(genes0,genes1)                colnames(genes) <-                                paste0("Gene",                1                :p)                rownames(genes) <-                                paste0("Subject field",                1                :n)                return(genes) }  genes <-                                sim.expr.data(n =                100,                n0 =                50,                p =                100,                rho.0 =                0.01,                rho.1 =                0.95)                # checking for positive definite matrix called tt                if                (!                all(eigen(tt)$values                >                                                0)) {                bulletin("eta * sigma2 * kin not PD, using Matrix::nearPD")   tt <-                Matrix::                nearPD(tt)$mat }

Documentation

In RStudio, go to Aid --> Roxygen Quick Reference

Refer to Table viii.i and Tabular array 8.2 for a summary of the near commonly used roxygen2 tags and formatting tags for creating function documentation.

Table eight.1: Common `roxygen2` tags to use in creating documentation for R functions (Peng, Kross, and Anderson 2017)
Tag	Pregnant
@return	A clarification of the object returned by the office
@parameter	Caption of a office parameter
@inheritParams	Name of a function from which to get parameter definitions
@examples	Example code showing how to use the function
@details	Add more details on how the office works (for example, specifics of the algorithm beingness used)
@notation	Add together notes on the office or its use
@source	Add whatever details on the source of the code or ideas for the role
@references	Add any references relevant to the function
@importFrom	Import a function from another bundle to use in this function (this is especially useful for inline functions like %>% and %within%)
@export	Export the function, so users will have direct access to it when they load the package

Table eight.two: Common `roxygen2` formatting tags used in creating documentation for R functions (Peng, Kross, and Anderson 2017)
Tag	Meaning
\code{}	Format in a typeface to look similar code
\dontrun{}	Apply with examples, to avoid running the example code during parcel builds and testing
\link{}	Link to another R office
\eqn{}{}	Include an inline equation
\deqn{}{}	Include a display equation (i.e., shown on its own line)
\itemize{}	Create an itemized listing
\url{}	Include a web link
\href{}{}	Include a web link

`usethis` functions

Here are some of the primal functions included in usethis and what they do:

Useful **devtools** functions¶
Function	Employ
use_data	Save an object in your R session equally a dataset in the packet
use_description	Set the parcel to include a DESCRIPTION file
use_namespace	Fix up the bundle to include a NAMESPACE file
use_vignette	Gear up upwards the package to include a vignette
use_travis	Gear up travis ci
use_appveyor	Set appveyor
use_testthat	Prepare folders for testing
use_test	Create exam file named by the function argument in the correct folder
use_readme_rmd	Set up the package to include a README file in Rmarkdown format
use_build_ignore	Specify files that should be ignored when building the R package (for example, if you take a folder where you're drafting a journal article nigh the package, y'all can include all related files in a folder that you ready to exist ignored during the package build)
use_cran_comments	Create a file where y'all tin can add comments to include with your CRAN submission.
use_news_md	Add a file to the parcel to give news on changes in new versions

References

Allaire, JJ, Yihui Xie, Jonathan McPherson, Javier Luraschi, Kevin Ushey, Aron Atkins, Hadley Wickham, Joe Cheng, Winston Chang, and Richard Iannone. 2019. Rmarkdown: Dynamic Documents for R. https://rmarkdown.rstudio.com.

Bryan, Jenny, STAT545TAs, and Jim Hester. 2019. Happy Git and Github for the useR. https://happygitwithr.com/.

Xie, Yihui, J.J. Allaire, and Garrett Grolemund. 2018. R Markdown: The Definitive Guide. Boca Raton, Florida: Chapman; Hall/CRC. https://bookdown.org/yihui/rmarkdown.

hallfeembirl.blogspot.com

Source: https://sahirbhatnagar.com/rpkg/

Hall Feembirl

Appveyor We Encountered an Internal Error Please Try Again

Introduction

Pre-workshop set up-upwardly

Git and GitHub

Introduction

Annotations

Stride i: Create a remote repo

Stride 2: New `RStudio` Project via `git clone`

Stride 3: `add` and `commit` your changes

Pace 4: `push` your local commits

Step 5: Open the repo with `GitKraken`

Discussion

Edifice an `R` package

Package Structure

Getting Started

Step 1: Cheque working directory

Pace 2: Add required `R` package files

Step 3: Configure `RStudio` build options

Step 4: Build and install

Step 5: Fill in the blanks and commit changes

Step six: Add together a dataset

Footstep 7: Certificate the dataset

Step eight: Add an `R` function

Step nine: Certificate the `R` function

Step 10: Dependencies: What does your package need?

Step xi: Check your package

Vignettes

Continous Integration

Travis and Appveyor

Using Travis

Using AppVeyor

Tests

Another example

Documentation

`usethis` functions

References

Publicar un comentario for "Appveyor We Encountered an Internal Error Please Try Again"

Appveyor We Encountered an Internal Error Please Try Again

Introduction

Pre-workshop set up-upwardly

Git and GitHub

Introduction

Annotations

Stride i: Create a remote repo

Stride 2: New RStudio Project via git clone

Stride 3: add and commit your changes

Pace 4: push your local commits

Step 5: Open the repo with GitKraken

Discussion

Edifice an R package

Package Structure

Getting Started

Step 1: Cheque working directory

Pace 2: Add required R package files

Step 3: Configure RStudio build options

Step 4: Build and install

Step 5: Fill in the blanks and commit changes

Step six: Add together a dataset

Footstep 7: Certificate the dataset

Step eight: Add an R function

Step nine: Certificate the R function

Step 10: Dependencies: What does your package need?

Step xi: Check your package

Vignettes

Continous Integration

Travis and Appveyor

Using Travis

Using AppVeyor

Tests

Another example

Documentation

usethis functions

References

Publicar un comentario for "Appveyor We Encountered an Internal Error Please Try Again"

Stride 2: New `RStudio` Project via `git clone`

Stride 3: `add` and `commit` your changes

Pace 4: `push` your local commits

Step 5: Open the repo with `GitKraken`

Edifice an `R` package

Pace 2: Add required `R` package files

Step 3: Configure `RStudio` build options

Step eight: Add an `R` function

Step nine: Certificate the `R` function

`usethis` functions