Creating packages based on the previous workshop for this user group.
Release process based on the useR!2021 talk
Maintaining packages based on the archived packages files.
For R User Group Ghana on their 3rd anniversary
LluΓs Revilla Sancho
IDIBAPS, CIBEREHD
2022/01/16
(updated: 2022-01-15 )
Creating packages based on the previous workshop for this user group.
Release process based on the useR!2021 talk
Maintaining packages based on the archived packages files.
Creating packages based on the previous workshop for this user group.
Release process based on the useR!2021 talk
Maintaining packages based on the archived packages files.
Packages provide a mechanism for loading optional code, data and documentation as needed.
Packages provide a mechanism for loading optional code, data and documentation as needed.
Code
Most common usage
Packages provide a mechanism for loading optional code, data and documentation as needed.
Code
Data
Most common usage
Less used due to restrictions on size on CRAN
Packages provide a mechanism for loading optional code, data and documentation as needed.
Code
Data
Documentation
Most common usage
Less used due to restrictions on size on CRAN
In my opinion the most important aspect.
Many resources!
Many resources!
You can also find help online (always check the etiquette)
Asking your local community: R User Group Ghana
Asking on Twitter #rstats
Asking on Stack Overflow
Asking on RStudio forum
Resources used to create this workshop
MaΓ«lle post: how to write good packages is also recommended.
.github
folder: Files specific to GitHub (this isn't necessary/Advanced content) man
folder with *.rd files: your documentation. tests
folder: Check the code of the package. vignette
folder: Long documentation; not just examples. .Rbuildignore
: A file describing what to omit when building the package. DESCRIPTION
file: Summary and description of the package. LICENSE
file: The conditions under the package is released. NAMESPACE
file: What this package shares and needs. NEWS
file: What has changed since last release. README
: How to install and why this packages is needed and some basic examples. Package: my_packageTitle: Short Descriptiono in Title CaseVersion: 0.0.9000Authors@R: c(person(given = "Name", role = c("aut", "cre", "cph"), email = "my@email.com"), ...)Description: A long description of the packageLicense: MIT + file LICENSEDepends: R (>= 4.1.2)Imports: methodsSuggests: covr, knitrVignetteBuilder: knitrEncoding: UTF-8Language: en-USRoxygen: list(markdown = TRUE)RoxygenNote: 7.1.1
Name of the package, description of the package, maintainer, relationships with other packages... Language does not need to be on English, it can be in other languages
Package: my_packageTitle: Short Descriptiono in Title CaseVersion: 0.0.9000Authors@R: c(person(given = "Name", role = c("aut", "cre", "cph"), email = "my@email.com"), ...)Description: A long description of the packageLicense: MIT + file LICENSEDepends: R (>= 4.1.2)Imports: methodsSuggests: covr, knitrVignetteBuilder: knitrEncoding: UTF-8Language: en-USRoxygen: list(markdown = TRUE)RoxygenNote: 7.1.1
Package: Name (ASCII characters and . and -).
Title: Short description.
Version: At least two numbers.Authors@R
: Information with an author (auth) and maintainer (cre).
Description: Longer description.
License: Information about the copyright.
Depends: Packages needed without which the package doesn't work.
Imports: Packages used.
Suggests: Packages used on examples or vignettes.
VignetteBuilder: How to build the vignette.
Other optional fields:
Name of the package, description of the package, maintainer, relationships with other packages... Language does not need to be on English, it can be in other languages
Only valid R code: functions, objects, environments that don't depend on previous code executed.
If a function uses a function of an other package use package::function
Add that package to the appropriate site on Description
add a #' @importFrom package function
(See next slide)
meow <- function() { message("meow")}
Import code of other packages and export code of your package:
import(dplyr)importFrom(methods, is)export(meow)
This can be done manually no need to do it via other tools (but recommended)
Import code of other packages and export code of your package:
import(dplyr)importFrom(methods, is)export(meow)
If using roxygen2 you can use:
#' @import dplyr#' @importFrom methods isis_meow <- function(x){ methods(x, "meow")}#' @export # To make it available to othersmeow <- function() { message("meow")}
Which will be written to the NAMESPACE file when updating the documentation
This can be done manually no need to do it via other tools (but recommended)
Important file!
Using roxygen2:
#' Check if it is a meow#'#' Check if object is of class meow.#' @param x A character string.#'#' @return A logical value with either TRUE or FALSE #' if the object is a meow.#' @export#' @examples#' is_meow("hi")#' @importFrom methods isis_meow <- function(x){ methods(x, "meow")}
Convert this specials comments into *.Rd files with:
document()
In Rstudio you can insert the skeleton with Ctrl+Alt+Shift+R . In Rstudio you can convert the special comments into documentation with Ctrl+Shift+D .
Articles are like vignettes but not checked by R CMD check
Articles are like vignettes but not checked by R CMD check
With testthat, tinytest or other ways
Vignettes and articles
Tests
Website for the documentation of the package
Articles are like vignettes but not checked by R CMD check
With testthat, tinytest or other ways
Sites with pkgdown or other tools.
Vignettes and articles
Tests
Website for the documentation of the package
Compiled code
Articles are like vignettes but not checked by R CMD check
With testthat, tinytest or other ways
Sites with pkgdown or other tools.
C++, C, Fortran or linking to other languages, Java, perl; or other programs (cURl, xmldev)
Vignettes and articles
Tests
Website for the documentation of the package
Compiled code
Other
Articles are like vignettes but not checked by R CMD check
With testthat, tinytest or other ways
Sites with pkgdown or other tools.
C++, C, Fortran or linking to other languages, Java, perl; or other programs (cURl, xmldev)
How to choose a name of the package.
How to write a good README and NEWS file.
Set up continuous integration tests.
How to pick up a license.
Sharing with others
A my_package.tar.gz
file
Sharing with others
A my_package.tar.gz
file
Built with R CMD build my_package
What does it mean? Building R CMD build
and making it accessible to other people, example: install.packages("http://biodev.cea.fr/sgcca/gliomaData_0.4.tar.gz", repos = NULL)
What are the expectations?
Git repository, svn, or none
Repositories keep versions of code
Git repository, svn, or none
CRAN, Bioconductor, Zenodo
Repositories keep versions of code
Archive do not delete content (normally)
Keep versions "released".
Only CRAN, Bioconductor and additional repositories like r-universe, drat, ... work via install.packages
.
Git repository, svn, or none
CRAN, Bioconductor, Zenodo
GitHub + R-universe + (rOpenSci) + CRAN/Bioconductor + Zenodo
Repositories keep versions of code
Archive do not delete content (normally)
Keep versions "released".
Only CRAN, Bioconductor and additional repositories like r-universe, drat, ... work via install.packages
.
Able to combine them, not mutually-exclusive
Goals of a submission
Submissions are though specially if coming from places with poor training Lack of confidence/experience with reviews.
Goals of a submission
Archives reviewing packages | Objectives of the reviews? |
---|---|
CRAN | Non-trivial publication quality packages. |
Bioconductor | Promote high-quality, well documented and interoperable. |
rOpenSci | Drive the adoption of best practices with useful, transparent and constructive feedback. |
Submissions are though specially if coming from places with poor training Lack of confidence/experience with reviews.
Differences in objectives but all looking for quality CRAN: Point errors, comments Bioconductor: In detail comment of style, classes, dependencies, structureβ¦ rOpenSci: guideline for reviewers (about style, tests, functions, description, documentation, β¦)
CRAN ~18000 packages, Bioconductor ~2000, rOpenSci ~300 To work with this slides use xaringan::infinite_moon_reader()
Goals of a submission
Archives reviewing packages | Objectives of the reviews? |
---|---|
CRAN | Non-trivial publication quality packages. |
Bioconductor | Promote high-quality, well documented and interoperable. |
rOpenSci | Drive the adoption of best practices with useful, transparent and constructive feedback. |
Pick the right for you and your users
Submissions are though specially if coming from places with poor training Lack of confidence/experience with reviews.
Differences in objectives but all looking for quality CRAN: Point errors, comments Bioconductor: In detail comment of style, classes, dependencies, structureβ¦ rOpenSci: guideline for reviewers (about style, tests, functions, description, documentation, β¦)
CRAN ~18000 packages, Bioconductor ~2000, rOpenSci ~300 To work with this slides use xaringan::infinite_moon_reader()
CRAN | Bioconductor | rOpenSci | |
---|---|---|---|
Guides | R-exts | Website | Book |
Submit | tar.gz file | fill an issue | fill an issue |
Review | email & ftp | Github | Github |
Setup | None | ssh key, subscribe mailing | CI tests |
Checks | check --as-cran | check; BiocCheck | check --as-cran |
OS | Windows, Unix, iOS | Windows, Unix, iOS | Windows, Unix, iOS |
Versions | oldrel, release, patched, devel | release, devel | oldrel, release, devel |
Cycle | Always open | 2 annual releases | Always open |
Editors | 0 | 0 | ~10 |
Reviewers | ~5 Volunteers | ~10+Volunteers | Volunteers |
Different setup, different review.
The different projects/archives have different setups. Read the table All of them first you need to pass the automatic checks in place before a human looks into it. Will use data from the three projects but mostly refer to CRAN.
One order of magnitude of difference between each other CRAN > Bioconductor > rOpenSci Many variability on month Also very few data collected from CRAN so far (Also there are some hiccups on CRAN collection, near the end of May the CRON job stopped working for a week. )
Many folders but these two are the most important. There isn't an explanation from CRAN about how do they work. Pretest is resubmission (newer versions of packages) and also for newbies
Submit when you are ready, better on the queue than outside.
Reviews are short, brief and to the point.
Median time on submissions ~9 hours, mean time ~31.4254531 hours. 1, 2, 9, 31.4254531, 33, 2365
Expect 3-7 days till your new package is on CRAN.
Different time, can be shorter or longer. Most longer need resubmission. Resubmit with different version (makes it easier to track how many are).
## # A tibble: 2 Γ 2## new time## <chr> <dbl>## 1 New 58## 2 Update 5
CRAN: 60h Bioconductor: most of them in 1 month rOpenSci: in 2 months (seeking 2 reviewers and posting them).
Bioconductor reviewers do a lot rOpenSci editors too Both organizations have a group of users involved on the package review system. Even if Bioconductor doesn't explicitly ask for reviewers from the community. Bioconductor are considering now how to improve the review system. Omitted bots bioc-issue-bot and ropensci-review-bot (new March 2021).
A dialog between authors and reviewers & editors.
Non reviewers users on bioconductor still chime in to help.
Bot helps on the process and changes with the process
Bot provides feedback of many issues and actions performed. It can be changed/adapted to change in requirements or errors. rOpenSci is going to have a bot too ropensci-review-bot.
Labels are used to indicate progress on the submission.
On bioconductor most problems with the submissions are not the package itself but not replying or chosing another venue. rOpenSci provides more detailed questioning for scope of a package.
Bioconductor & rOpenSci 50%, some submissions are abandoned or do not fit the project. Different problems faced by new packages and older ones. More in depth review requires 1 month for each reviewer.
## # A tibble: 50 Γ 7## submission_n new Accepted n perc suspended perc_suspended## <fct> <chr> <lgl> <int> <dbl> <dbl> <dbl>## 1 1 New FALSE 652 17.8 652 31.0 ## 2 1 New TRUE 3015 82.2 0 0 ## 3 1 Update FALSE 691 13.4 691 32.8 ## 4 1 Update TRUE 4456 86.6 0 0 ## 5 2 New FALSE 148 23.4 148 7.03## 6 2 New TRUE 485 76.6 0 0 ## 7 2 Update FALSE 270 8.27 270 12.8 ## 8 2 Update TRUE 2993 91.7 0 0 ## 9 3 New FALSE 41 20.4 41 1.95## 10 3 New TRUE 160 79.6 0 0 ## # β¦ with 40 more rows
## # A tibble: 2 Γ 3## Approved n perc## <chr> <int> <dbl>## 1 No 1233 0.505## 2 Yes 1208 0.495
## # A tibble: 1 Γ 4## `1. awaiting moderation` `2. review in progress` `3a. accepted` `3b. declined`## <dbl> <dbl> <dbl> <dbl>## 1 0.0000231 0.299 35.7 19.1
name | Median days | Total days |
---|---|---|
1/editor-checks | 2.8 | 2.8 |
2/seeking-reviewer(s) | 2.4 | 5.2 |
3/reviewer(s)-assigned | 7.1 | 12.3 |
4/review(s)-in-awaiting-changes | 27.0 | 39.3 |
5/awaiting-reviewer(s)-response | 17.1 | 56.3 |
6/approved | 13.3 | 69.6 |
Prepare
Manual to create R packages, R Packages
Follow policies (CRAN) and guidelines (Bioconductor, rOpenSci).
Follow the detailed guidelines from Bioconductor and rOpenSci. Fix any problem that you haven't detected previously (double check the CRAN repository policy). Resubmit
Via web or devtools::release()
.
Nervous
Wait..
Resubmit
Fix and explain on re-submission.
Via web or devtools::release()
.
Nervous
Wait..
Resubmit
Fix and explain on re-submission.
π Celebrate π
Announce to the community:
π₯ R-packages mailing list
π¦ Social media
πͺ Family?
Parties interested: users, R-user-groups, ...
Changes on R code, changes on dependencies, changes on CRAN checks.
Not in your hands to control, reactive work
Changes on R code, changes on dependencies, changes on CRAN checks.
Evaluate how to adapt your package
Not in your hands to control, reactive work
Better quality => Less work
Changes on R code, changes on dependencies, changes on CRAN checks.
Evaluate how to adapt your package
Provide new releases
Not in your hands to control, reactive work
Better quality => Less work
Check also your dependencies and be mindful to users
New features
Whenever you want
On Bioconductor only after each release
Be mindful that you now "need" to support this.
New features
Whenever you want
On Bioconductor only after each release
Deprecating features/breaking changes
.Deprecated
Be mindful that you now "need" to support this.
New features
Whenever you want
On Bioconductor only after each release
Deprecating features/breaking changes
.Deprecated
.defunct
Be mindful that you now "need" to support this.
New features
Whenever you want
On Bioconductor only after each release
Deprecating features/breaking changes
.Deprecated
.defunct
Be mindful that you now "need" to support this.
Deprecate and defunct are important steps to notify users.
Be mindful also to other developers that depend on your package: give them time, hear their concerns...
New features
Whenever you want
On Bioconductor only after each release
Deprecating features/breaking changes
.Deprecated
.defunct
Make life easy to users and developers
Be mindful that you now "need" to support this.
Deprecate and defunct are important steps to notify users.
Be mindful also to other developers that depend on your package: give them time, hear their concerns...
Packages might be archived from repositories
Understand why happened.
Fix and resubmit
(Your package will need to pass the new package checks again.)
CRAN | Packages | Proportion |
---|---|---|
no | 3091 | 60% |
yes | 2063 | 40% |
Many archived packages return to CRAN.
π§ Creating a package is easy.
π¦ Releasing a package is doable.
βοΈ Maintaining the high standards is not.
π§ Creating a package is easy.
π¦ Releasing a package is doable.
βοΈ Maintaining the high standards is not.
Thanks to the R core team past and current members.
Thanks to the CRAN, Bioconductor, rOpenSci teams.
All the contributors to packages used to make this presentation.
π§ Creating a package is easy.
π¦ Releasing a package is doable.
βοΈ Maintaining the high standards is not.
Thanks to the R core team past and current members.
Thanks to the CRAN, Bioconductor, rOpenSci teams.
All the contributors to packages used to make this presentation.
To you!
Thank also to the package authors (mainly tidyverse, ggplot2 and rhub, and gh). MaΓ«lle Salmon and Stephanie Locke for the CRAN dashboard. And the organization. rOpenSci review: Video
## NULL
Creating packages based on the previous workshop for this user group.
Release process based on the useR!2021 talk
Maintaining packages based on the archived packages files.
Keyboard shortcuts
β, β, Pg Up, k | Go to previous slide |
β, β, Pg Dn, Space, j | Go to next slide |
Home | Go to first slide |
End | Go to last slide |
Number + Return | Go to specific slide |
b / m / f | Toggle blackout / mirrored / fullscreen mode |
c | Clone slideshow |
p | Toggle presenter mode |
t | Restart the presentation timer |
?, h | Toggle this help |
o | Tile View: Overview of Slides |
Esc | Back to slideshow |
For R User Group Ghana on their 3rd anniversary
LluΓs Revilla Sancho
IDIBAPS, CIBEREHD
2022/01/16
(updated: 2022-01-15 )
Creating packages based on the previous workshop for this user group.
Release process based on the useR!2021 talk
Maintaining packages based on the archived packages files.
Creating packages based on the previous workshop for this user group.
Release process based on the useR!2021 talk
Maintaining packages based on the archived packages files.
Packages provide a mechanism for loading optional code, data and documentation as needed.
Packages provide a mechanism for loading optional code, data and documentation as needed.
Code
Most common usage
Packages provide a mechanism for loading optional code, data and documentation as needed.
Code
Data
Most common usage
Less used due to restrictions on size on CRAN
Packages provide a mechanism for loading optional code, data and documentation as needed.
Code
Data
Documentation
Most common usage
Less used due to restrictions on size on CRAN
In my opinion the most important aspect.
Many resources!
Many resources!
You can also find help online (always check the etiquette)
Asking your local community: R User Group Ghana
Asking on Twitter #rstats
Asking on Stack Overflow
Asking on RStudio forum
Resources used to create this workshop
MaΓ«lle post: how to write good packages is also recommended.
.github
folder: Files specific to GitHub (this isn't necessary/Advanced content) man
folder with *.rd files: your documentation. tests
folder: Check the code of the package. vignette
folder: Long documentation; not just examples. .Rbuildignore
: A file describing what to omit when building the package. DESCRIPTION
file: Summary and description of the package. LICENSE
file: The conditions under the package is released. NAMESPACE
file: What this package shares and needs. NEWS
file: What has changed since last release. README
: How to install and why this packages is needed and some basic examples. Package: my_packageTitle: Short Descriptiono in Title CaseVersion: 0.0.9000Authors@R: c(person(given = "Name", role = c("aut", "cre", "cph"), email = "my@email.com"), ...)Description: A long description of the packageLicense: MIT + file LICENSEDepends: R (>= 4.1.2)Imports: methodsSuggests: covr, knitrVignetteBuilder: knitrEncoding: UTF-8Language: en-USRoxygen: list(markdown = TRUE)RoxygenNote: 7.1.1
Name of the package, description of the package, maintainer, relationships with other packages... Language does not need to be on English, it can be in other languages
Package: my_packageTitle: Short Descriptiono in Title CaseVersion: 0.0.9000Authors@R: c(person(given = "Name", role = c("aut", "cre", "cph"), email = "my@email.com"), ...)Description: A long description of the packageLicense: MIT + file LICENSEDepends: R (>= 4.1.2)Imports: methodsSuggests: covr, knitrVignetteBuilder: knitrEncoding: UTF-8Language: en-USRoxygen: list(markdown = TRUE)RoxygenNote: 7.1.1
Package: Name (ASCII characters and . and -).
Title: Short description.
Version: At least two numbers.Authors@R
: Information with an author (auth) and maintainer (cre).
Description: Longer description.
License: Information about the copyright.
Depends: Packages needed without which the package doesn't work.
Imports: Packages used.
Suggests: Packages used on examples or vignettes.
VignetteBuilder: How to build the vignette.
Other optional fields:
Name of the package, description of the package, maintainer, relationships with other packages... Language does not need to be on English, it can be in other languages
Only valid R code: functions, objects, environments that don't depend on previous code executed.
If a function uses a function of an other package use package::function
Add that package to the appropriate site on Description
add a #' @importFrom package function
(See next slide)
meow <- function() { message("meow")}
Import code of other packages and export code of your package:
import(dplyr)importFrom(methods, is)export(meow)
This can be done manually no need to do it via other tools (but recommended)
Import code of other packages and export code of your package:
import(dplyr)importFrom(methods, is)export(meow)
If using roxygen2 you can use:
#' @import dplyr#' @importFrom methods isis_meow <- function(x){ methods(x, "meow")}#' @export # To make it available to othersmeow <- function() { message("meow")}
Which will be written to the NAMESPACE file when updating the documentation
This can be done manually no need to do it via other tools (but recommended)
Important file!
Using roxygen2:
#' Check if it is a meow#'#' Check if object is of class meow.#' @param x A character string.#'#' @return A logical value with either TRUE or FALSE #' if the object is a meow.#' @export#' @examples#' is_meow("hi")#' @importFrom methods isis_meow <- function(x){ methods(x, "meow")}
Convert this specials comments into *.Rd files with:
document()
In Rstudio you can insert the skeleton with Ctrl+Alt+Shift+R . In Rstudio you can convert the special comments into documentation with Ctrl+Shift+D .
Articles are like vignettes but not checked by R CMD check
Articles are like vignettes but not checked by R CMD check
With testthat, tinytest or other ways
Vignettes and articles
Tests
Website for the documentation of the package
Articles are like vignettes but not checked by R CMD check
With testthat, tinytest or other ways
Sites with pkgdown or other tools.
Vignettes and articles
Tests
Website for the documentation of the package
Compiled code
Articles are like vignettes but not checked by R CMD check
With testthat, tinytest or other ways
Sites with pkgdown or other tools.
C++, C, Fortran or linking to other languages, Java, perl; or other programs (cURl, xmldev)
Vignettes and articles
Tests
Website for the documentation of the package
Compiled code
Other
Articles are like vignettes but not checked by R CMD check
With testthat, tinytest or other ways
Sites with pkgdown or other tools.
C++, C, Fortran or linking to other languages, Java, perl; or other programs (cURl, xmldev)
How to choose a name of the package.
How to write a good README and NEWS file.
Set up continuous integration tests.
How to pick up a license.
Sharing with others
A my_package.tar.gz
file
Sharing with others
A my_package.tar.gz
file
Built with R CMD build my_package
What does it mean? Building R CMD build
and making it accessible to other people, example: install.packages("http://biodev.cea.fr/sgcca/gliomaData_0.4.tar.gz", repos = NULL)
What are the expectations?
Git repository, svn, or none
Repositories keep versions of code
Git repository, svn, or none
CRAN, Bioconductor, Zenodo
Repositories keep versions of code
Archive do not delete content (normally)
Keep versions "released".
Only CRAN, Bioconductor and additional repositories like r-universe, drat, ... work via install.packages
.
Git repository, svn, or none
CRAN, Bioconductor, Zenodo
GitHub + R-universe + (rOpenSci) + CRAN/Bioconductor + Zenodo
Repositories keep versions of code
Archive do not delete content (normally)
Keep versions "released".
Only CRAN, Bioconductor and additional repositories like r-universe, drat, ... work via install.packages
.
Able to combine them, not mutually-exclusive
Goals of a submission
Submissions are though specially if coming from places with poor training Lack of confidence/experience with reviews.
Goals of a submission
Archives reviewing packages | Objectives of the reviews? |
---|---|
CRAN | Non-trivial publication quality packages. |
Bioconductor | Promote high-quality, well documented and interoperable. |
rOpenSci | Drive the adoption of best practices with useful, transparent and constructive feedback. |
Submissions are though specially if coming from places with poor training Lack of confidence/experience with reviews.
Differences in objectives but all looking for quality CRAN: Point errors, comments Bioconductor: In detail comment of style, classes, dependencies, structureβ¦ rOpenSci: guideline for reviewers (about style, tests, functions, description, documentation, β¦)
CRAN ~18000 packages, Bioconductor ~2000, rOpenSci ~300 To work with this slides use xaringan::infinite_moon_reader()
Goals of a submission
Archives reviewing packages | Objectives of the reviews? |
---|---|
CRAN | Non-trivial publication quality packages. |
Bioconductor | Promote high-quality, well documented and interoperable. |
rOpenSci | Drive the adoption of best practices with useful, transparent and constructive feedback. |
Pick the right for you and your users
Submissions are though specially if coming from places with poor training Lack of confidence/experience with reviews.
Differences in objectives but all looking for quality CRAN: Point errors, comments Bioconductor: In detail comment of style, classes, dependencies, structureβ¦ rOpenSci: guideline for reviewers (about style, tests, functions, description, documentation, β¦)
CRAN ~18000 packages, Bioconductor ~2000, rOpenSci ~300 To work with this slides use xaringan::infinite_moon_reader()
CRAN | Bioconductor | rOpenSci | |
---|---|---|---|
Guides | R-exts | Website | Book |
Submit | tar.gz file | fill an issue | fill an issue |
Review | email & ftp | Github | Github |
Setup | None | ssh key, subscribe mailing | CI tests |
Checks | check --as-cran | check; BiocCheck | check --as-cran |
OS | Windows, Unix, iOS | Windows, Unix, iOS | Windows, Unix, iOS |
Versions | oldrel, release, patched, devel | release, devel | oldrel, release, devel |
Cycle | Always open | 2 annual releases | Always open |
Editors | 0 | 0 | ~10 |
Reviewers | ~5 Volunteers | ~10+Volunteers | Volunteers |
Different setup, different review.
The different projects/archives have different setups. Read the table All of them first you need to pass the automatic checks in place before a human looks into it. Will use data from the three projects but mostly refer to CRAN.
One order of magnitude of difference between each other CRAN > Bioconductor > rOpenSci Many variability on month Also very few data collected from CRAN so far (Also there are some hiccups on CRAN collection, near the end of May the CRON job stopped working for a week. )
Many folders but these two are the most important. There isn't an explanation from CRAN about how do they work. Pretest is resubmission (newer versions of packages) and also for newbies
Submit when you are ready, better on the queue than outside.
Reviews are short, brief and to the point.
Median time on submissions ~9 hours, mean time ~31.4254531 hours. 1, 2, 9, 31.4254531, 33, 2365
Expect 3-7 days till your new package is on CRAN.
Different time, can be shorter or longer. Most longer need resubmission. Resubmit with different version (makes it easier to track how many are).
## # A tibble: 2 Γ 2## new time## <chr> <dbl>## 1 New 58## 2 Update 5
CRAN: 60h Bioconductor: most of them in 1 month rOpenSci: in 2 months (seeking 2 reviewers and posting them).
Bioconductor reviewers do a lot rOpenSci editors too Both organizations have a group of users involved on the package review system. Even if Bioconductor doesn't explicitly ask for reviewers from the community. Bioconductor are considering now how to improve the review system. Omitted bots bioc-issue-bot and ropensci-review-bot (new March 2021).
A dialog between authors and reviewers & editors.
Non reviewers users on bioconductor still chime in to help.
Bot helps on the process and changes with the process
Bot provides feedback of many issues and actions performed. It can be changed/adapted to change in requirements or errors. rOpenSci is going to have a bot too ropensci-review-bot.
Labels are used to indicate progress on the submission.
On bioconductor most problems with the submissions are not the package itself but not replying or chosing another venue. rOpenSci provides more detailed questioning for scope of a package.
Bioconductor & rOpenSci 50%, some submissions are abandoned or do not fit the project. Different problems faced by new packages and older ones. More in depth review requires 1 month for each reviewer.
## # A tibble: 50 Γ 7## submission_n new Accepted n perc suspended perc_suspended## <fct> <chr> <lgl> <int> <dbl> <dbl> <dbl>## 1 1 New FALSE 652 17.8 652 31.0 ## 2 1 New TRUE 3015 82.2 0 0 ## 3 1 Update FALSE 691 13.4 691 32.8 ## 4 1 Update TRUE 4456 86.6 0 0 ## 5 2 New FALSE 148 23.4 148 7.03## 6 2 New TRUE 485 76.6 0 0 ## 7 2 Update FALSE 270 8.27 270 12.8 ## 8 2 Update TRUE 2993 91.7 0 0 ## 9 3 New FALSE 41 20.4 41 1.95## 10 3 New TRUE 160 79.6 0 0 ## # β¦ with 40 more rows
## # A tibble: 2 Γ 3## Approved n perc## <chr> <int> <dbl>## 1 No 1233 0.505## 2 Yes 1208 0.495
## # A tibble: 1 Γ 4## `1. awaiting moderation` `2. review in progress` `3a. accepted` `3b. declined`## <dbl> <dbl> <dbl> <dbl>## 1 0.0000231 0.299 35.7 19.1
name | Median days | Total days |
---|---|---|
1/editor-checks | 2.8 | 2.8 |
2/seeking-reviewer(s) | 2.4 | 5.2 |
3/reviewer(s)-assigned | 7.1 | 12.3 |
4/review(s)-in-awaiting-changes | 27.0 | 39.3 |
5/awaiting-reviewer(s)-response | 17.1 | 56.3 |
6/approved | 13.3 | 69.6 |
Prepare
Manual to create R packages, R Packages
Follow policies (CRAN) and guidelines (Bioconductor, rOpenSci).
Follow the detailed guidelines from Bioconductor and rOpenSci. Fix any problem that you haven't detected previously (double check the CRAN repository policy). Resubmit
Via web or devtools::release()
.
Nervous
Wait..
Resubmit
Fix and explain on re-submission.
Via web or devtools::release()
.
Nervous
Wait..
Resubmit
Fix and explain on re-submission.
π Celebrate π
Announce to the community:
π₯ R-packages mailing list
π¦ Social media
πͺ Family?
Parties interested: users, R-user-groups, ...
Changes on R code, changes on dependencies, changes on CRAN checks.
Not in your hands to control, reactive work
Changes on R code, changes on dependencies, changes on CRAN checks.
Evaluate how to adapt your package
Not in your hands to control, reactive work
Better quality => Less work
Changes on R code, changes on dependencies, changes on CRAN checks.
Evaluate how to adapt your package
Provide new releases
Not in your hands to control, reactive work
Better quality => Less work
Check also your dependencies and be mindful to users
New features
Whenever you want
On Bioconductor only after each release
Be mindful that you now "need" to support this.
New features
Whenever you want
On Bioconductor only after each release
Deprecating features/breaking changes
.Deprecated
Be mindful that you now "need" to support this.
New features
Whenever you want
On Bioconductor only after each release
Deprecating features/breaking changes
.Deprecated
.defunct
Be mindful that you now "need" to support this.
New features
Whenever you want
On Bioconductor only after each release
Deprecating features/breaking changes
.Deprecated
.defunct
Be mindful that you now "need" to support this.
Deprecate and defunct are important steps to notify users.
Be mindful also to other developers that depend on your package: give them time, hear their concerns...
New features
Whenever you want
On Bioconductor only after each release
Deprecating features/breaking changes
.Deprecated
.defunct
Make life easy to users and developers
Be mindful that you now "need" to support this.
Deprecate and defunct are important steps to notify users.
Be mindful also to other developers that depend on your package: give them time, hear their concerns...
Packages might be archived from repositories
Understand why happened.
Fix and resubmit
(Your package will need to pass the new package checks again.)
CRAN | Packages | Proportion |
---|---|---|
no | 3091 | 60% |
yes | 2063 | 40% |
Many archived packages return to CRAN.
π§ Creating a package is easy.
π¦ Releasing a package is doable.
βοΈ Maintaining the high standards is not.
π§ Creating a package is easy.
π¦ Releasing a package is doable.
βοΈ Maintaining the high standards is not.
Thanks to the R core team past and current members.
Thanks to the CRAN, Bioconductor, rOpenSci teams.
All the contributors to packages used to make this presentation.
π§ Creating a package is easy.
π¦ Releasing a package is doable.
βοΈ Maintaining the high standards is not.
Thanks to the R core team past and current members.
Thanks to the CRAN, Bioconductor, rOpenSci teams.
All the contributors to packages used to make this presentation.
To you!
Thank also to the package authors (mainly tidyverse, ggplot2 and rhub, and gh). MaΓ«lle Salmon and Stephanie Locke for the CRAN dashboard. And the organization. rOpenSci review: Video
## NULL