rusda

[FranzKrah]

```

• 1. What does this package do?
     An interface to the web service methods provided by the
     United States Department of Agriculture (USDA). The
     Agricultural Research Service (ARS) provides a large
     set of databases. The current version of the package
     holds interfaces to the Systematic Botany and Mycology
     Laboratory (SMML), which consists of four databases:
     Fungus-Host Distributions, Specimens, Literature and
     the Nomenclature database. It provides functions for
     querying these databases. The main function is
     \code{associations}, which allows searching for fungus-
     host combinations.
• 1. Paste the full DESCRIPTION file inside a code block (bounded by ``` on either end).

Package: rusda
Type: Package
Title: Interface to USDA databases
Version: 1.0
Date: 2015-06-25
Author: Franz-Sebastian Krah
Maintainer: Franz-Sebastian Krah <f.krah@mailbox.org>
Imports: XML, httr, plyr, foreach, stringr
Description: An interface to the web service methods 
provided by the United States Department of Agriculture 
(USDA). The Agricultural Research Service (ARS) 
provides a large set of databases. The current version 
of the package holds interfaces to the Systematic 
Botany and Mycology Laboratory (SMML), which consists 
of four databases: Fungus-Host Distributions, 
Specimens, Literature and the Nomenclature database. It 
provides functions for querying these databases. The 
main function is \code{associations}, which allows 
searching for fungus-host combinations. 
License: GPL (>= 2)
URL: http://www.usda.gov/wps/portal/usda/usdahome, 
http://nt.ars-grin.gov/fungaldatabases/index.cfm

• 3. URL for the package (the development repository, not a stylized html page)
     https://github.com/FranzKrah/rusda
• 4. What data source(s) does it work with (if applicable)?
     species vector (class: character)defined in R
• 5. Who is the target audience?
     Botanists; Mycologists; Plant pathologists; Plant protection; People interested in fungus-host interactions or associations;
• 6. Are there other R packages that accomplish the same thing? If so, what is different about yours?
     No.
• 7. Check the box next to each policy below, confirming that you agree. These are mandatory.
  • This package does not violate the Terms of Service of any service it interacts with.
  • The repository has continuous integration with Travis and/or another service
  • The package contains a vignette
  • The package contains a reasonably complete readme with devtools install instructions
  • The package contains unit tests
  • The package only exports functions to the NAMESPACE that are intended for end users
• 1. Do you agree to follow the rOpenSci packaging guidelines? These aren't mandatory, but we strongly suggest you follow them. If you disagree with anything, please explain.
  • Are there any package dependencies not on CRAN?
  • Do you intend for this package to go on CRAN?
    Yes.
  • Does the package have a CRAN accepted license? No. First rOpenSci
  • Did devtools::check() produce any errors or warnings? If so paste them below.
    Updating rusda documentation
    Loading rusda
    First time using roxygen2 4.0. Upgrading automatically...
    '/Library/Frameworks/R.framework/Resources/bin/R' --no-site-file --no-environ --no-save --no-restore CMD
    build '/Users/test/Documents/R/pkgs/rusda' --no-resave-data --no-manual
• checking for file ‘/Users/test/Documents/R/pkgs/rusda/DESCRIPTION’ ... OK
• preparing ‘rusda’:
• checking DESCRIPTION meta-information ... OK
• checking for LF line-endings in source and make files
• checking for empty or unneeded directories
• building ‘rusda_1.0.tar.gz’

'/Library/Frameworks/R.framework/Resources/bin/R' --no-site-file --no-environ --no-save --no-restore CMD
check '/var/folders/js/s5k7qtzd1kz2pt9t2p11z7600000gn/T//RtmpopOjFp/rusda_1.0.tar.gz' --timings

• using log directory ‘/private/var/folders/js/s5k7qtzd1kz2pt9t2p11z7600000gn/T/RtmpopOjFp/rusda.Rcheck’
• using R version 3.2.0 (2015-04-16)
• using platform: x86_64-apple-darwin13.4.0 (64-bit)
• using session charset: UTF-8
• checking for file ‘rusda/DESCRIPTION’ ... OK
• checking extension type ... Package
• this is package ‘rusda’ version ‘1.0’
• checking package namespace information ... OK
• checking package dependencies ... OK
• checking if this is a source package ... OK
• checking if there is a namespace ... OK
• checking for executable files ... OK
• checking for hidden files and directories ... OK
• checking for portable file names ... OK
• checking for sufficient/correct file permissions ... OK
• checking whether package ‘rusda’ can be installed ... OK
• checking installed package size ... OK
• checking package directory ... OK
• checking DESCRIPTION meta-information ... OK
• checking top-level files ... NOTE
  Non-standard files/directories found at top level:
  ‘Readme.Rmd’ ‘Readme.html’
• checking for left-over files ... OK
• checking index information ... OK
• checking package subdirectories ... OK
• checking R files for non-ASCII characters ... OK
• checking R files for syntax errors ... OK
• checking whether the package can be loaded ... OK
• checking whether the package can be loaded with stated dependencies ... OK
• checking whether the package can be unloaded cleanly ... OK
• checking whether the namespace can be loaded with stated dependencies ... OK
• checking whether the namespace can be unloaded cleanly ... OK
• checking use of S3 registration ... OK
• checking dependencies in R code ... OK
• checking S3 generic/method consistency ... OK
• checking replacement functions ... OK
• checking foreign function calls ... OK
• checking R code for possible problems ... OK
• checking Rd files ... OK
• checking Rd metadata ... OK
• checking Rd line widths ... OK
• checking Rd cross-references ... OK
• checking for missing documentation entries ... OK
• checking for code/documentation mismatches ... OK
• checking Rd \usage sections ... OK
• checking Rd contents ... OK
• checking for unstated dependencies in examples ... OK
• checking examples ... OK
• checking PDF version of manual ... OK
• DONE

Status: 1 NOTE

• 9. Please add explanations below for any exceptions to the above:
• 10. If this is a resubmission following rejection, please explain the change in cirucmstances.

[sckott]

@jooolia assigned

[jooolia]

Comments:

Overall rusda seems to a be useful package for getting data from the USDA databases for getting information about fungal-host associations and literature.

Installation:

With Windows:

This might be specific to my setup, but I had a small problem as I had the "httr" package already installed and then when installing rusda the install failed on "httr". This removed my "httr" package. I re-installed "httr" and then installed rusda easily. I wonder if adding a minimum version to the "httr" package required could fix this problem? e.g. imports: httr (>= 1.0.0)

With Linux:

No problems installing.

Code Overall:

Code is well-commented and functions have clear purpose. Functions are small, modular and logically divided up into different script files.

Specific comments about the scripts and functions:

associations.R

In the help file under the argument "database" it says that valid input are "HF", "SP" or "both", but when I alter the example to use only "HF" or "SP" I get an error message:
Error in get.HF(tax[[i]], process, spec.type = spec.type) : task 1 failed - "cannot coerce type 'closure' to vector of type 'character'"

Also if I do not give an argument to database I get a warning message with the defaults:
hosts <- associations(spec, clean=FALSE, syn.include=FALSE, spec.type="fungus", process=FALSE)

Warning messages: 1: In if (database == "HF") { : the condition has length > 1 and only the first element will be used 2: In if (database == "SP") { : the condition has length > 1 and only the first element will be used 3: In if (database == "both") { : the condition has length > 1 and only the first element will be used

Ropensci criteria:

Package name:

• nice choice.

Function and variable naming:

• minor note: Ropensci recommends snake case for functions and variable naming. Argument spec.type would become spec_type and get.HF would become get_HF and so on.

Coding style:

• generally very good and easy to follow.
• minor note: more spacing around operators could improve readability of code. See Hadley Wickam's R package book for what I mean.

Readme:

• Readme.Rmd is clear, provides clear instructions on how to install and useful examples.
  -In the readme there is a small typo in the header "An other example" should be "Another example"

Code of conduct:

• Consider adding a code of conduct to your project to make it easy and welcoming for people to contribute. You could look into devtools::use_code_of_conduct()

Documentation:

• Looks good.
  -The documentation files are generally good, but you could consider adding a bit more detail about the type of data you will receive.
• You could consider adding a vignette with use as a way to make the package even more user-friendly.

Examples:

• Examples work and illustrate the important features of the package.

Recommended scaffolding:

• All good here.

Testing:

• No tests. Could consider adding tests or even assertions. One spot this might be useful is for the input types argument. Instead of a warning this could be tested and if not an informative message is given to the user.

Console messages:

• good use of message() and warning() for communication with user. There are some times when cat() is used instead of message(), you could consider revising to use message() instead for these.

I hope these comments are helpful and please let me know if anything is unclear in these comments. I am also happy to try out any revisions/changes and discuss further.

[jooolia]

Regarding installation issues related to httr it seems to be not localized to this package. See @sckott has had this problem: https://gist.github.com/sckott/1e2df73a56283e842245 and is investigating.

[FranzKrah]

Hi Julia,

thank you very much for the constructive thoughts.
I corrected the critical points and now I think the package is more user friendly.
I set httr to httr (>= 1.0.0) in the description file. Is hope thats correct.

How would you test for correct specification of ‘spec_type’? The input would have to be matched against a taxonomy, like with rgbif and
if its nor the correct kingdom there should be a warning message? This would be time consuming for longer input vectors.
I don’t see a fast way how to check for the correct input. Thought about that before, too…

Please let me know if you find further improvements.

Cheers,
Franz

Franz Krah (B.Sc)
Personal Webpage: http://franzkrah.github.io http://franzkrah.github.io/
University: http://www.biodiv.wzw.tum.de/index.php?id=18 http://www.biodiv.wzw.tum.de/index.php?id=18

On 10 Jul 2015, at 18:06, Julia Gustavsen notifications@github.com wrote:

Comments:

Overall rusda seems to a be useful package for getting data from the USDA databases for getting information about fungal-host associations and literature.

Installation:

With Windows:

This might be specific to my setup, but I had a small problem as I had the "httr" package already installed and then when installing rusda the install failed on "httr". This removed my "httr" package. I re-installed "httr" and then installed rusda easily. I wonder if adding a minimum version to the "httr" package required could fix this problem? e.g. imports: httr (>= 1.0.0)

With Linux:

No problems installing.

Code Overall:

Code is well-commented and functions have clear purpose. Functions are small, modular and logically divided up into different script files.

Specific comments about the scripts and functions:

associations.R

In the help file under the argument "database" it says that valid input are "HF", "SP" or "both", but when I alter the example to use only "HF" or "SP" I get an error message:
Error in get.HF(tax[[i]], process, spec.type = spec.type) :
task 1 failed - "cannot coerce type 'closure' to vector of type 'character'"

Also if I do not give an argument to database I get a warning message with the defaults:
hosts <- associations(spec, clean=FALSE, syn.include=FALSE,
spec.type="fungus", process=FALSE)

Warning messages:
1: In if (database == "HF") { :
the condition has length > 1 and only the first element will be used
2: In if (database == "SP") { :
the condition has length > 1 and only the first element will be used
3: In if (database == "both") { :
the condition has length > 1 and only the first element will be used

Ropensci criteria:

Package name:

nice choice.
Function and variable naming:

minor note: Ropensci recommends snake case for functions and variable naming. Argument spec.type would become spec_type and get.HF would become get_HF and so on.
Coding style:

generally very good and easy to follow.
minor note: more spacing around operators could improve readability of code. See Hadley Wickam's R package book http://r-pkgs.had.co.nz/r.html for what I mean.
Readme:

Readme.Rmd is clear, provides clear instructions on how to install and useful examples. -In the readme there is a small typo in the header "An other example" should be "Another example"
Code of conduct:

Consider adding a code of conduct to your project to make it easy and welcoming for people to contribute. You could look into devtools::use_code_of_conduct()
Documentation:

Looks good. -The documentation files are generally good, but you could consider adding a bit more detail about the type of data you will receive.
You could consider adding a vignette with use as a way to make the package even more user-friendly.
Examples:

Examples work and illustrate the important features of the package.
Recommended scaffolding:

All good here.
Testing:

No tests. Could consider adding tests or even assertions. One spot this might be useful is for the input types argument. Instead of a warning this could be tested and if not an informative message is given to the user.
Console messages:

good use of message() and warning() for communication with user. There are some times whencat()is used instead ofmessage(), you could consider revising to usemessage()` instead for these.
I hope these comments are helpful and please let me know if anything is unclear in these comments. I am also happy to try out any revisions/changes and discuss further.

—
Reply to this email directly or view it on GitHub #18 (comment).

[FranzKrah]

Ahh forgot. The new version is on GitHub now!!
Cheers

Franz Krah (B.Sc)
Personal Webpage: http://franzkrah.github.io http://franzkrah.github.io/
University: http://www.biodiv.wzw.tum.de/index.php?id=18 http://www.biodiv.wzw.tum.de/index.php?id=18

On 11 Jul 2015, at 13:28, f.krah@mailbox.org wrote:

Hi Julia,

thank you very much for the constructive thoughts.
I corrected the critical points and now I think the package is more user friendly.
I set httr to httr (>= 1.0.0) in the description file. Is hope thats correct.

How would you test for correct specification of ‘spec_type’? The input would have to be matched against a taxonomy, like with rgbif and
if its nor the correct kingdom there should be a warning message? This would be time consuming for longer input vectors.
I don’t see a fast way how to check for the correct input. Thought about that before, too…

Please let me know if you find further improvements.

Cheers,
Franz

Franz Krah (B.Sc)
Personal Webpage: http://franzkrah.github.io http://franzkrah.github.io/
University: http://www.biodiv.wzw.tum.de/index.php?id=18 http://www.biodiv.wzw.tum.de/index.php?id=18

On 10 Jul 2015, at 18:06, Julia Gustavsen <notifications@github.com mailto:notifications@github.com> wrote:

Comments:

Overall rusda seems to a be useful package for getting data from the USDA databases for getting information about fungal-host associations and literature.

Installation:

With Windows:

This might be specific to my setup, but I had a small problem as I had the "httr" package already installed and then when installing rusda the install failed on "httr". This removed my "httr" package. I re-installed "httr" and then installed rusda easily. I wonder if adding a minimum version to the "httr" package required could fix this problem? e.g. imports: httr (>= 1.0.0)

With Linux:

No problems installing.

Code Overall:

Code is well-commented and functions have clear purpose. Functions are small, modular and logically divided up into different script files.

Specific comments about the scripts and functions:

associations.R

In the help file under the argument "database" it says that valid input are "HF", "SP" or "both", but when I alter the example to use only "HF" or "SP" I get an error message:
Error in get.HF(tax[[i]], process, spec.type = spec.type) :
task 1 failed - "cannot coerce type 'closure' to vector of type 'character'"

Also if I do not give an argument to database I get a warning message with the defaults:
hosts <- associations(spec, clean=FALSE, syn.include=FALSE,
spec.type="fungus", process=FALSE)

Warning messages:
1: In if (database == "HF") { :
the condition has length > 1 and only the first element will be used
2: In if (database == "SP") { :
the condition has length > 1 and only the first element will be used
3: In if (database == "both") { :
the condition has length > 1 and only the first element will be used

Ropensci criteria:

Package name:

nice choice.
Function and variable naming:

minor note: Ropensci recommends snake case for functions and variable naming. Argument spec.type would become spec_type and get.HF would become get_HF and so on.
Coding style:

generally very good and easy to follow.
minor note: more spacing around operators could improve readability of code. See Hadley Wickam's R package book http://r-pkgs.had.co.nz/r.html for what I mean.
Readme:

Readme.Rmd is clear, provides clear instructions on how to install and useful examples. -In the readme there is a small typo in the header "An other example" should be "Another example"
Code of conduct:

Consider adding a code of conduct to your project to make it easy and welcoming for people to contribute. You could look into devtools::use_code_of_conduct()
Documentation:

Looks good. -The documentation files are generally good, but you could consider adding a bit more detail about the type of data you will receive.
You could consider adding a vignette with use as a way to make the package even more user-friendly.
Examples:

Examples work and illustrate the important features of the package.
Recommended scaffolding:

All good here.
Testing:

No tests. Could consider adding tests or even assertions. One spot this might be useful is for the input types argument. Instead of a warning this could be tested and if not an informative message is given to the user.
Console messages:

good use of message() and warning() for communication with user. There are some times whencat()is used instead ofmessage(), you could consider revising to usemessage()` instead for these.
I hope these comments are helpful and please let me know if anything is unclear in these comments. I am also happy to try out any revisions/changes and discuss further.

—
Reply to this email directly or view it on GitHub #18 (comment).

[jooolia]

Hi Franz,

Glad you appreciated the comments and I see you've adapted a lot of your code, added a vignette and code of conduct. 😄

Sorry I was unclear about the testing for species type. I agree it would be onerous to check for existence of specific taxa. I was referring the the spec_type argument which seems like it should be either "plant" or "fungus". For example in associations.R you have warning(" Make sure spec_type is correctly specified! \n \n" , immediate. = TRUE, call.= FALSE). My simple idea was that you could formalize that using something like this:

library(testthat)
expect_match(spec_type, ("fungus|plant"))

What do you think?

I had a quick run through the updated code and looks good, but had a small problem with associations()

spec <- "Fagus sylvatica"
pathogens <- associations(spec, database="HF", clean=TRUE, syn_include=TRUE,
 spec_type="plant", process=TRUE)

gives me the output:

Warning:  Make sure spec_type is correctly specified! 
 ... retrieving data ... for:
Fagus sylvatica
... extracting Synonyms ...
... cleaning step ...
Error in lapply(res, clean_step, taxa = taxa, syns = syns, spec_type = spec_type,  : 
  object 'res' not found

whereas with database="both" or database="SP" I get the desired output.:

Warning:  Make sure spec_type is correctly specified! 
 ... retrieving data ... for:
Fagus sylvatica
... extracting Synonyms ...
... extracting Fungus-Hosts DB ...
... extracting Specimens DB ...
... cleaning step ...

Warning:  Make sure spec_type is correctly specified! 
 ... retrieving data ... for:
Fagus sylvatica
... extracting Synonyms ...
... extracting Specimens DB ...
... cleaning step ...

[FranzKrah]

Hi Julia,

yes, I think the package improved a lot!

So again you are right. If the “expect_match” condition had been present before
the reason for your error would be obvious ;-)
I changed “HF” to “FH” since the database name is “Fungus-Hosts” and not
“Hosts-Fungus database”…

Please let me know further errors, etc.

Cheers,
Franz

Julia Gustavsen notifications@github.com hat am 13. Juli 2015 um 20:38
geschrieben:

Hi Franz,

Glad you appreciated the comments and I see you've adapted a lot of your code,
added a vignette and code of conduct. 😄

Sorry I was unclear about the testing for species type. I agree it would be
onerous to check for existence of specific taxa. I was referring the the
spec_type argument which seems like it should be either "plant" or "fungus".
For example in associations.R you have warning(" Make sure spec_type is correctly specified! \n \n" , immediate. = TRUE, call.= FALSE). My simple
idea was that you could formalize that using something like this:

library(testthat)
expect_match(spec_type, ("fungus|plant"))

What do you think?

I had a quick run through the updated code and looks good, but had a small
problem with associations()

spec <- "Fagus sylvatica"
pathogens <- associations(spec, database="HF", clean=TRUE, syn_include=TRUE,
 spec_type="plant", process=TRUE)

gives me the output:

Warning:  Make sure spec_type is correctly specified! 
 ... retrieving data ... for:
Fagus sylvatica
... extracting Synonyms ...
... cleaning step ...
Error in lapply(res, clean_step, taxa = taxa, syns = syns, spec_type =
spec_type,  : 
  object 'res' not found

whereas with database="both" or database="SP" I get the desired output.:

Warning:  Make sure spec_type is correctly specified! 
 ... retrieving data ... for:
Fagus sylvatica
... extracting Synonyms ...
... extracting Fungus-Hosts DB ...
... extracting Specimens DB ...
... cleaning step ...

Warning:  Make sure spec_type is correctly specified! 
 ... retrieving data ... for:
Fagus sylvatica
... extracting Synonyms ...
... extracting Specimens DB ...
... cleaning step ...

---

Reply to this email directly or view it on GitHub:
#18 (comment)

MSc. Franz Krah
Mycology, Phylogenetics, PCM
http://www.biodiv.wzw.tum.de/index.php?id=18

[jooolia]

Hi Franz,

Ok nice improvements. 👍 I think this looks good.

@sckott I think we are ready for the next step with this. How to proceed?

[FranzKrah]

Hey Julia,

just wanted to know if this has been really been CCd to Scott?

Best,Franz

BSc. Franz Krah
Mobile: 0170 5221189
Ecology, Phylogenetic Comparative Methods
Personal Webpage: http://franzkrah.github.io http://franzkrah.github.io/
University: http://www.biodiv.wzw.tum.de/index.php?id=18 http://www.biodiv.wzw.tum.de/index.php?id=18

On 15 Jul 2015, at 19:27, Julia Gustavsen notifications@github.com wrote:

Hi Franz,

Ok nice improvements. I think this looks good.

@sckott https://github.com/sckott I think we are ready for the next step with this. How to proceed?

—
Reply to this email directly or view it on GitHub #18 (comment).