generated from r4ds/bookclub-template
-
Notifications
You must be signed in to change notification settings - Fork 18
/
99-r-cmd-check.Rmd
178 lines (128 loc) · 7.49 KB
/
99-r-cmd-check.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
# (PART) Appendices {-}
# R CMD CHECK
## R CMD CHECK
- `R CMD CHECK` is the terminal command
- `devtools::check()` and running `Ctrl/Cmd + Shift + E` run it indirectly.
`devtools::check()` also does:
- updates documentation (`devtools::document()`)
- bundles before checking (bit safer as it removes unnecessary files)
- sets the `NOT_CRAN` environment variable to `TRUE`.
### Results
- `ERROR`s: Severe problems that you should fix regardless of whether or not you’re submitting to CRAN.
- `WARNING`s: Likely problems that you must fix if you’re planning to submit to CRAN (and a good idea to look into even if you’re not).
- `NOTE`s: Mild problems. If you are submitting to CRAN, you should strive to eliminate all NOTEs, even if they are false positives. If you have no NOTEs, human intervention is not required, and the package submission process will be easier. If it’s not possible to eliminate a NOTE, you’ll need describe why it’s OK in your submission comments, as described in Section 22.2. If you’re not submitting to CRAN, carefully read each NOTE, but don’t go out of your way to fix things that you don’t think are problems.
- pkgs with compiled code may have larger than "allowed" file size. This appears as a NOTE as is no big problem - you can just mention this in the `cran-comments.md` in the submission.
## Checks
50 checks - for a full list, see the book.
The categories of checks are:
- metadata
- package structure
- files are where they should be and there aren't any non-standard top level files
- it can be installed
- package size isn't > 5MB
- in short: lots of pain that can be alleviated by using `{usethis}` for making any new files
- `DESCRIPTION`
- `License: ____` must refer to a known license (https://svn.r-project.org/R/trunk/share/licenses/license.db) or must be a `file LICENSE` and the file must exist
- All dependencies including `Suggests` must be installed
- Every package listed in `Depends` must also be imported in the `NAMESPACE` or accessed with `pkg::foo`. If you don’t do this, your package will work when attached to the search path (with `library(mypackage)`) because it will also be attaching those packages that it depends on but will not work when only loaded (e.g. `mypackage::foo()`). In terms of good practice: don't use Depends and always access other packages that your package depends on using `pkg::foo`.
- `NAMESPACE`
- R code
- checks R scripts for errors - unlikely to get many issues here since they would have cropped up when running `devtools::load_all()` (which you probably would have before running a check)
- can't access functions from other packages which aren't exported (`:::`)
- you are not allowed to use `:::` to access non-exported functions from other packages. Either ask the package maintainer to export the function you need, or write your own version of it using exported functions. Alternatively, if the licenses are compatible you can copy and paste the exported function into your own package. If you do this, remember to update `Authors@R`.
- S3 generic/method consistency
```r
print <- function(x, ...){
UseMethod("print")
}
# BAD
print.my_class <- function(x) {
cat("Hi")
}
# GOOD
print.my_class <- function(x, ...) {
cat("Hi")
}
# Also ok
print.my_class <- function(x, ..., my_arg = TRUE) {
cat("Hi")
}
```
- Don’t use `assign()` to modify objects in the global environment. If you need to maintain state across function calls, create your own environment with `e <- new.env(parent = emptyenv())` and set and get values in it:
```r
e <- new.env(parent = emptyenv())
add_up <- function(x) {
if (is.null(e$last_x)) {
old <- 0
} else {
old <- e$last_x
}
new <- old + x
e$last_x <- new
new
}
add_up(10)
#> [1] 10
add_up(20)
#> [1] 30
```
- Don't use `T` or `F` in your functions - use `TRUE` and `FALSE`
- Data
- Documentation
- checks for completeness in all documentation and all man/*.Rd files have correct syntax
- checks maximum linewidth
- checks examples in help files (can use `devtools::run_examples()` to check these alone)
- Demos
- Compiled Code
- checks all foreign function calls with in compiled code
- runs all tests (`devtools::test()`)
- if the `devtools::test()` passes but test within the `R CMD CHECK` fails, there's something that's changed in your testing environment and it can be tricky to figure out. I've found restarting R before running `devtools::test()` seems to make the problem apparent.
- Vignettes
- checks for dependencies in vignettes and that the files are in right place within the pkg directory
- builds the vignettes
- running vignettes requires that the package is installed (`devtools::install()`)
- can be pretty slow - if you're wanting to quicky iterate through `check()`s and focus on other problems in your package:
- add `--no-build-vignettes` to "Build Source Packages" field in project options
- `devtools::check(vignettes=FALSE)`
## Meeting Videos
### Cohort 3
`r knitr::include_url("https://www.youtube.com/embed/QOKMXNn1X5o")`
<details>
<summary> Meeting chat log </summary>
```
00:48:13 Brendan Lam: I don't know what CRAN reviews, but ROpenSci is pretty transparent about how they do software review: https://devguide.ropensci.org/
01:00:06 Arun Chavan: omg
01:03:13 Brendan Lam: Thanks Collin! You've done an exceptionally good job leading this cohort.
01:05:48 Arun Chavan: https://dslcio.slack.com/archives/C0183F9UC2V/p1659977487900379
01:06:22 collinberke: https://dslcio.slack.com/archives/C0183F9UC2V/p1659977487900379
01:08:19 collinberke: https://avehtari.github.io/ROS-Examples/
01:11:12 Brendan Lam: Same
```
</details>
### Cohort 4
`r knitr::include_url("https://www.youtube.com/embed/dmk4CG9ILvE")`
`r knitr::include_url("https://www.youtube.com/embed/fuFjAj1_Xq0")`
<details>
<summary> Meeting chat log </summary>
```
00:08:43 Data Science Learning Community: New Zealand has extreme insects: https://en.wikipedia.org/wiki/Dryococelus_australis
00:10:57 Rebecca Butler: (popping in as a fly on the wall even though I've never made a meeting for this club)
00:29:41 Olivier Leroy: Am the only one that use CRAN view ?
00:40:10 Olivier Leroy: GitHub is starting to be really smart on it repo recommandation
00:49:28 Olivier Leroy: Company that sell data products do not sometimes want their package public
00:50:31 Olivier Leroy: Dealing with a lot of private package we have a lot of credentials issues (mainly bad practices)
00:58:06 Olivier Leroy: For the users one package make it easier, one example could be {sf}
00:58:27 Olivier Leroy: Default is that it is hard to build around {sf}
01:08:03 Jenny Bryan: The Pragmatic Programmer
01:08:56 Data Science Learning Community: https://www.manning.com/books/the-programmers-brain
01:10:50 Rebecca Butler: I want to see a list of the blogs Jenny follows :)
01:11:11 Olivier Leroy: Reacted to "I want to see a list..." with 👍
01:17:39 Data Science Learning Community: Non-defaults in RStudio: usethis::use_blank_slate()
01:18:58 Olivier Leroy: Thank you!
01:19:03 Gus Lipkin: Thank you!
01:19:06 Rebecca Butler: Thank you for your time, Jenny!
01:19:12 Schafer, Toryn: Thank you!
01:19:13 Ryan McShane: Thank you, and thank you for Happy Git with R!
01:19:14 Neil Birrell: Thanks so much for your time and mahi on the book and packages Jenny!
```
</details>