[R-pkg-devel] Should a package run without calling library?
Dear fellow R package maintainers,
I would enjoy your advice to clarify a CRAN policy issue.
The question is: should a package be able to work, when calling its exported
functions using the scope operator? Or, in the example code below, should #1
work?
```
# 1. Scope operator: should this always work?
mypackage::myfunction()
# Possible error message:
# Error in myfunction() :
# object 'myhiddenfunction' of mode 'function' was not found
# 2. Calling library first
library(mypackage)
myfunction()
```
I feel the answer is 'yes, #1 should work', as I feel this is only indirectly a
CRAN repository policy [1] , the IMHO relevant one which I quote: 'Packages
should not modify the global environment (user’s workspace).'. This means that
if I have a function that calls `mypackage::myfunction`, it will call `library`:
```
#' Function in another package, that depends on my package
do_something <- function() {
library(mypackage)
myfunction()
}
```
So, should a package be able to work, when calling its exported functions using
the scope operator?
Thanks for your advice/pointers, Richel Bilderbeek
* [1] <https://mirror.las.iastate.edu/CRAN/web/packages/policies.html>
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Package that needs installation URL to function optimally eligible for CRAN
Dear fellow package developers, I send this email for advice whether if I should submit a package to CRAN. I have written a GPL-3 licensed package, that allows one to install and use a command-line tool. This command-line tool, however, has a restriction: it is to be used by academics only. To be able to actually install it, there is a web form to request a download URL (valid for 4 hours). After confirmation of being an academic, one receives this URL by email. I feel the package on its own is useful enough to be put on CRAN. It 'R CMD check's cleanly without the install, yet if helps the install the command-line tool from the emailed URL (see <https://github.com/richelbilderbeek/netmhc2pan#install> ). Should I submit my package to CRAN? Thanks for your advice, Richel Bilderbeek __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] [SOLVED] Interpret feedback: not write testthat-tests in examples
Dear R package developers, Thanks so much for the generous responses! In summary: - one should usually not write tests in examples, that's what the 'tests' folder is for - if there is a demonstration, use a simple stopifnot, as one cannot assume a regular reader knows about the testthat package Thanks again and the best, Richel Bilderbeek __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Interpret feedback: not write testthat-tests in examples
Dear R package developers, I would enjoy some help regarding some feedback I got on my package from a CRAN volunteer, as I am unsure how to interpret this correctly. This is the feedback I got (I added '[do]'): > Please [do] not write testthat-tests in your examples. I wonder if this is about using `testthat` or using tests in general. To simplify the context, say I wrote a package with a function called `add`, that adds two numbers. My example code would then be something like this: ``` library(testthat) expect_equal(add(1, 2), 3) ``` The first interpretation is about using `testthat`: maybe I should use base R (`stopifnot`) or another testing library (`testit`) or hand-craft it myself? The second interpretation is about using tests in example code. I like to actively demonstrate that my code works as expected. I checked the policies regarding examples, and I could not find a rule that I should refrain from doing so. What is the correct response to this feedback? Thanks for your guidance, Richel Bilderbeek __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
