devtools::install_github("CTU-Basel/CTUHelpR")
Load the package
# load the package
library(CTUHelpR)
# internal file of the package
path <- system.file("exdata", "file.txt",
package = "CTUHelpR")
# print it
print_file_content(file_path = path)
## Hello world!
# run tests, this assumes you are one directory up from the CTUHelpR dir
devtools::test("CTUHelpR")
# spell check
# ignore words character vector allows to exclude technical terms in the check
ignore_words <- c()
devtools::spell_check("CTUHelpR", ignore = ignore_words)
# lint the package -> should be clean
library(lintr)
lint_package("CTUHelpR", linters = with_defaults(camel_case_linter = NULL,
object_usage_linter = NULL,
line_length_linter(125)))
library(rmarkdown)
render("vignettes/CTUHelpR-package-vignette.Rmd",
output_format=c("pdf_document"))
The README file contains both standard text and interpreted R code.
It must therefore be compiled. Changes should be made in the README.Rmd
file and the file "knited" with R. This is easiest with RStudio, but other
methods are available.
library(knitr)
knit("README.Rmd")
library(pkgdown)
build_site()
Dependencies to other R packages are to be declared in the DESCRIPTION
file under Imports:
and in
the specific roxygen2
documentation of the functions relying on the dependency. It is suggested to
be as explicit as possible. i.e. Just import functions that are needed and not entire packages.
Example to import str_match
str_length
str_wrap
from the stringr
package:
#' @importFrom stringr str_match str_length str_wrap
# build the package archive
R CMD build CTUHelpR
# check the archive (should return "Status: OK", no WARNINGs, no NOTEs)
# in this example for version 0.0.1
R CMD check CTUHelpR_0.0.1.tar.gz
Requests for new features and bug fixes should first be documented as an
Issue on GitHub.
Subsequently, in order to contribute to this R package you should fork the main repository.
After you have made your changes please run the
tests
and
lint your code as
indicated above. Please also increment the version number and recompile the
README.md
to increment the dev-version badge (requires installing the
package after editing the DESCRIPTION
file). If all tests pass and linting
confirms that your coding style conforms you can send a pull request (PR).
Changes should also be mentioned in the NEWS
file. A test has been implemented
to remind you to make these changes (see here).
The PR should have a description to help the reviewer understand what has been
added/changed. New functionalities must be thoroughly documented, have examples
and should be accompanied by at least one test to ensure long term
robustness. The PR will only be reviewed if all travis and AppVeyor checks are successful.
The person sending the PR should not be the one merging it.