EOGrady21
commented
4 years ago Here is a task list from the notes provided by CRAN
-
[ ] Check with @kevinsorochan for references that could be added to the description, my initial thought is that any references which would be useful are not yet published and this may be added to a later version of the package
-
[x] Adjust author formatting
-
[x] Change \dontrun{} to \donttest{} where necessary, remove where possible After attempting this, examples will not work properly because they require more external files (eg. CTD data), I will write a note to CRAN maintainers and hope that they allow it to pass.
-
[x] edit print() / cat() to message() / warning() Some of the print/ cat lines were left because they do not print to console, they create diagnostic text files for troubleshooting
-
[x] Check for edit of user settings eg. par() or working directory, use on.exit() if necessary
Thanks,
If there are references describing the methods in your package, please add these in the description field of your DESCRIPTION file in the form authors (year)
authors (year)
authors (year, ISBN:...)
or if those are not available:
with no space after 'doi:', 'arXiv:', 'https:' and angle brackets for
auto-linking.
(If you want to add a title as well please put it in quotes: "Title")
Please rather use the Authors@R field and declare Maintainer, Authors and Contributors with their appropriate roles with person() calls. e.g. something like: Authors@R: c(person("Alice", "Developer", role = c("aut", "cre","cph"), email = "alice.developer@some.domain.net"), person("Bob", "Dev", role = "aut") )
\dontrun{} should only be used if the example really cannot be executed (e.g. because of missing additional software, missing API keys, ...) by the user. That's why wrapping examples in \dontrun{} adds the comment ("# Not run:") as a warning for the user. Does not seem necessary. Please unwrap the examples if they are executable in < 5 sec, or replace \dontrun{} with \donttest{}.
You write information messages to the console that cannot be easily suppressed. It is more R like to generate objects that can be used to extract the information a user is interested in, and then print() that object. Instead of print()/cat() rather use message()/warning() or if(verbose)cat(..) (or maybe stop()) if you really have to write text to the console. (except for print, summary, interactive functions)
Please make sure that you do not change the user's options, par or working directory. If you really have to do so within functions, please ensure with an immediate call of on.exit() that the settings are reset when the function is exited. e.g.: ... oldpar <- par(no.readonly = TRUE) # code line i on.exit(par(oldpar)) # code line i + 1 ... par(mfrow=c(2,2)) # somewhere after ... e.g.: If you're not familiar with the function, please check ?on.exit. This function makes it possible to restore options before exiting a function even if the function breaks. Therefore it needs to be called immediately after the option change within a function.
Is this email adress a mailing list? This is not allowed according to the CRAN policy.
Please fix and resubmit.