1. Final steps
Let's finalize our package.
2. R package structure
After the tests, we finalize our package by updating the DESCRIPTION file.
3. Package versions
One component of our DESCRIPTION file is the Version field.
Here is an example of the tidy package.
The best practice format for package versions follows the pattern of major-dot-minor-dot-patch-dot-development number, starting with zero-zero-zero-9000 as the default for newly created packages.
9000 as the development number signifies its status as a package in development.
4. Package version incrementing guidelines
The development number is rarely changed during development and is removed before release.
Patch number changes signify a bug fix. An increment is added if more bugs are fixed before additional functionality is added, like from 0-point-0-point-1 to 0-point-0-point-2.
A minor number increase signifies the addition of new functionality before initial release, and the patch number resets to zero.
A major number update to 1-point-0-point-0 indicates that all major functionality has been added to the package with existing noted bugs fixed, making it stable for release.
Incrementing the major number implies changes that would break old versions of code.
5. Update title, author, version, and description
Let's update the DESCRIPTION file for release.
The first update is to the Title field below the Package field. We update it to be a summary of the package functionality for distance, time, weight, and temperature.
The Version field comes next. We clear the development number and change our version to 0-point-1-point-0 to signify this initial release.
Next is the Authors field. ORCID stands for Open Researcher and Contributor ID. It is easy to obtain online but is not required. We add our name and email to the Authors field in a call to the R person function. The empty field corresponds to middle name. The role field refers to being both author and creator. If multiple people are listed on a package, the creator is the default maintainer of the package.
Lastly, we need to update the Description field. Here we explain in greater detail the package's purpose in paragraph format.
Notice the tab spacing done on both the Title and Description fields. The package will not build without these tabs if fields span multiple lines.
6. Documenting a data file
Now we document our data files. We create an R file with usethis's use_r function. This starts the temperature_data-dot-R file in the R directory.
Next edit the R file to add a roxygen2 header.
The first line is the header title summarizing the data with a newline following.
We then give a further description of the data.
The @format tag denotes it is a data frame and its size.
The backslash-describe option is how we denote the column values with backslash-item. The columns of value and unit are described.
We show an example of how to print the data.
Lastly, the R file itself contains the name of the data in a string outside of this roxygen2 header.
To build the help file for the data, we finish by running roxygenize.
7. What does devtools::check() look for?
With everything including our description file and datasets now documented and ready, we run a final check of our package using devtools' check function. It considers if the package can be installed, ensures the DESCRIPTION information is correct, checks for package dependencies, looks for any syntax errors in the code, confirms the presence of complete documentation, ensures successful test runs, and verifies if the all vignettes build successfully.
8. Running devtools::check()
The check function is a robust examination of our package. The GIF shows what the output might look like when we run it. Remember that the goal is zero errors, warnings, and notes. If we have errors, warnings, or notes, we can go back and check that specific part. Its important to carefully review the output from running this check.
9. Let's practice!
Wrap up your first package in the final exercises.