I was reviewing the functions and felt that it might be confusing that we ask the user to pass the package source path then things will fail if the package is not installed which is in another directory. Although some functions might not need the path of the package source.

For instance:

• rev_signature() could just take the name of the installed package since it does not call functionMap::map_r_package which requires the source path.

This is a modified version of rev_signature()

rev_signature2 <- function(package = "viridisLite"){
  check_if_installed(package)

  f_name <- unclass(utils::lsf.str(envir = asNamespace(package), all = TRUE))
  f_bare_args <- unlist(lapply(f_name, get_string_arguments, package = package))
  
  f_args <- paste0(f_name, " ", gsub("function ", "", f_bare_args))
  data.frame(f_name, f_args)
}

> rev_signature2("viridisLite")

• On the other hand functions like rev_signature(), rev_calls(), rev_args() call functionMap::map_r_package, so they need the source path.

So do you think sticking to the local path in all the functions even if they don't need it is the best option here?

Since there are different ways returning a dataframe, or iterating over a list, should we unify this?

For instance:

• should we pick either the apply or map family, and use it in all our functions?
• should we agree whether to return data.frame, dplyr::data_frame , tibble, etc.?
• Other ?

Stemming from a suggestion I made over on ropensci/software-review-meta#55 (comment), @noamross suggested I file this here.

The basic idea: As a reviewer, I look at the vignettes to look for ways to make the package better by making the vignettes either more comprehensible and also more comprehensive. A handy thing to have would be for a way to easily assess whether the vignettes are comprehensive and I think this could be done in a partially-automated fashion.

Things I think this feature could calculate quantities such as:

• Of the exported functions, how many are referenced in a vignette at least once?
• Of the exported functions, on average how many times is each referenced across all vignettes?
• Of the exported functions, which are not referenced in a vignette?
• Of the exported functions, which are not actually run in a vignette. i.e., are a lot of the exported functions in the vignettes but not actually run.

What are others' thoughts on this?

Unfortunately somebody beat you to the name: https://cran.r-project.org/web/packages/revtools/index.html

We know that functionMap::map_r_package() the function we use to pull all functions from a package, does not catch everything. Systematic misses should be added to this thread. We are aware of the following misses:

• Functions called with purrr::map

• Functions defined with setGeneric for example:

https://github.com/inbo/git2rdata/blob/master/R/read_vc.R

I get warnings when I run the shiny app on windows 10. I guess it is coming from shinyFiles::getVolumes()

Warning in file.info(files) :
  cannot open file 'C:/hiberfil.sys': The process cannot access the file because it is being used by another process
Warning in file.info(files) :
  cannot open file 'C:/pagefile.sys': The process cannot access the file because it is being used by another process
Warning in file.info(files) :
  cannot open file 'C:/PerfLogs': Access is denied
Warning in file.info(files) :
  cannot open file 'C:/swapfile.sys': The process cannot access the file because it is being used by another process
Warning in file.info(files) :
  cannot open file 'C:/System Volume Information': Access is denied
Warning in file.info(files) :
  cannot open file 'C:/$Recycle.Bin/S-1-5-18': Access is denied

I guess the same issue was raised in issue 57 in shinyFiles package.

Anyone else faced this with Windows or any other OS?

@jtr13

I thought about sth rough for a hex sticker as follows:

I tried hexSticker package to overlay an image on a hex sticket template, but I haven't reached a good form yet.

Any suggestions for other quick ways?

Just copying stuff over from ropensci/software-review-meta#18 since this repo is the home for such ideas. 😺

Initially from ropensci/software-review#125

• package has code of conduct
• exported functions are consistent in snake/camel naming convention
• preferred packages are used
• the global environment is not directly manipulated
• package has CI and badges
• package uses appveyor is compiled code is included
• common name conflicts are avoided
• If README has code, README.Rmd is used
• Package has a vignette
• Package has top level documentation
• CI doesn't skip tests

• could use available to check pkg name
• check if using roxygen style docs
• package has at least some tests
• check that all exported fxns have a @examples roxygen tag with at least 1 line of code (i.e., 1 example)
• might want to flag when people use Depends in DESCRIPTION to make sure it's really needed
• test of the package with different loading methods (see [this comment](https://github.com/ropensci/onboardi

@jtr13 @boshek @OmaymaS @maurolepore @lcolladotor @noamross according to our recently created package curation policy this repo should now be transferred to either one of your personal accounts, or the ropensci-archive organization.

If you don't answer within one month, I'll transfer the repository to ropensci-archive, after which you could still email me to transfer the repo to a personal account.

Thank you!

I have installed the package to test it, and I am wonder what is the stance of the package regarding S4 methods.

I tried in a new package I'm developing and they seem to be considered as not exported or not at all despite being on the NAMESPACE of the package:

In the picture it doesn't appear the methods such as modify that are implemented in the package (see llrs/GSEAdv)
I compared with mvbutils::foodweb(where = "package:GSEAdv")

And here it appears as a without links to internal functions (see on the right of the first line without lines above those terms with lines)
Thanks

Warning messages:
1: In vattrs[[name]][index] <- value :
  number of items to replace is not a multiple of replacement length
2: In `[<-.factor`(`*tmp*`, thisvar, value = 0) :
  invalid factor level, NA generated

I think the length issue is related to removing duplicates.

In skimr example, when skim_render() is clicked, is_windows and fix_unicode are labelled even though they are not dependents (icons are rendered correctly)

I tried to fix but I couldn't find the md files

Revise this:

https://github.com/ropenscilabs/pkginspector/blob/8116b61841190964c59862b92009498950b0a143/R/rev_args.R#L49-L51

So that it doesn't include .Internal.

I copy Stefanie's email here to facilitate discussion.

---------- Forwarded message ----------
From: Stefanie Butland [email protected]
Date: Thu, Jun 7, 2018 at 6:24 PM
Subject: guest rOpenSci blog post on pkginspector /pkgtests?
To: Omayma Said [email protected], "Albers, Sam ENV:EX" [email protected], Leonardo Collado Torres [email protected], Mauro Lepore [email protected], Joyce Robbins [email protected], Noam Ross [email protected]

Hi all,

What do you think of writing a guest post about your unconf18 pkginspector/pkgtests project for the rOpenSci blog? Please read on, decide among yourselves and then give me a yes or no with an approximate date for draft submission so we can review the post and give feedback before publishing.

If you're interested, when considering a theme for the post, it's good to lay out the motivation and approach and don't try to sound like you've managed to solve the problem with two days work :-)

Here are some project posts from unconf17: https://ropensci.org/tags/unconf17/ as examples. It would be ideal if everyone who contributed to the group is an author, though for some this could involve only reading and approving the draft post. Please make sure I didn't miss anyone on this email.

Here's the technical info: https://github.com/ropensci/roweb2#contributing-a-blog-post.
Please include these tags, among others you might choose:

• r
• package
• community
• unconf
• unconf18

Happy to answer any questions.

Cheers!

Stef Butland

It's very hard to make standardized tests for what to include in documentation, because things vary quite a bit. Nonetheless, there are a lot of things I'd like to know about the help files of a package I'm looking at, such as

• Do help files have @return fields? This is supposed to be a requirement for anything that returns an object, but it can't really be tested because there are lots of functions that don't return objects and that's a very difficult thing to parse.
• Are lots of functions aggregated together in one help file? At times this is OK, but a lot of times its a flag for overly confusing help files with many many arguments.

One idea would be to generate a table of help files, their length, whether they contain certain fields (examples, return value), and how many/which functions they contain.

Data-packages contain no functions. Running rev_dependency_usage() on packages with no functions result in error with uninformative message:

 Error in `[.data.frame`(`*tmp*`, , 2) : undefined columns selected 

I suggest checking for this issue and throwing informative error message or returning empty dataframe with warning.