Submission: readODS

[chainsawriot]

Date accepted: 2022-06-24
Submitting Author Name: Chung-hong Chan
Submitting Author Github Handle: @chainsawriot
Repository: https://github.com/chainsawriot/readODS
Version submitted: 1.7.0
Editor: @noamross
Reviewers: @emmamendelsohn, @adamhsparks

Due date for @emmamendelsohn: 2020-08-11

Due date for @adamhsparks: 2020-08-11
Archive: TBD
Version accepted: TBD

---

• Paste the full DESCRIPTION file inside a code block below:

Package: readODS
Type: Package
Title: Read and Write ODS Files
Version: 1.7.0
Date: 2020-06-22
Author: Gerrit-Jan Schutten, Chung-hong Chan, Thomas J. Leeper, John Foster,  and other contributors
Maintainer: Chung-hong Chan <chainsawtiney@gmail.com>
Contact: https://github.com/chainsawriot/readODS/
Description: Import ODS (OpenDocument Spreadsheet) into R as a data frame. Also support writing data frame into ODS file.
Imports:
    xml2 (>= 1.3.2),
    cellranger,
    readr (>= 1.2.1),
    stringi,
    utils
Suggests:
    dplyr,
    testthat,
    datasets,
    covr,
    knitr,
    rmarkdown
License: GPL-3
RoxygenNote: 7.1.0
Roxygen: list(markdown = TRUE)
VignetteBuilder: knitr

Scope

• Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):

  • data retrieval
  • data extraction
  • data munging
  • data deposition
  • workflow automataion
  • version control
  • citation management and bibliometrics
  • scientific software wrappers
  • field and lab reproducibility tools
  • database software bindings
  • geospatial data
  • text analysis

• Explain how and why the package falls under these categories (briefly, 1-2 sentences):

This package reads and writes OpenDocument Spreadsheet (ods) files.

• Who is the target audience and what are scientific applications of this package?

Researchers working with ods files

• Are there other R packages that accomplish the same thing? If so, how does yours differ or meet our criteria for best-in-category?

No

• If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted.

Technical checks

Confirm each of the following by checking the box.

• I have read the guide for authors and rOpenSci packaging guide.

This package:

• does not violate the Terms of Service of any service it interacts with.
• has a CRAN and OSI accepted license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions, created with roxygen2.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration, including reporting of test coverage using services such as Travis CI, Coveralls and/or CodeCov.

Publication options

• Do you intend for this package to go on CRAN?
• Do you intend for this package to go on Bioconductor?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:

JOSS Options

• The package has an obvious research application according to JOSS's definition.
  • The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
  • The package is deposited in a long-term repository with the DOI:
  • (Do not submit your package separately to JOSS)

• Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:

MEE Options

• The package is novel and will be of interest to the broad readership of the journal.
• The manuscript describing the package is no longer than 3000 words.
• You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see MEE's Policy on Publishing Code)
• (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no guarantee that your manuscript will be within MEE scope.)
• (Although not required, we strongly recommend having a full manuscript prepared when you submit here.)
• (Please do not submit your package separately to Methods in Ecology and Evolution)

Code of conduct

• I agree to abide by rOpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

[geanders]

@chainsawriot : Thank you very much for your submission! @noamross will be your editor for the peer review process.

[noamross]

Hello @chainsawriot, thanks for your submission!

Editor checks:

• Fit: The package meets criteria for fit and overlap
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has a CRAN or OSI accepted license
• Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

Here is the output of goodpractice::gp() with my comments. These are small but should be addressed in revision (they can wait until after reviews if you choose), and can be used by reviewers as entry points to the code. I am now seeking reviewers.

── GP readODS ────────────────────────────────────

It is good practice to

  ✖ write unit tests for all functions, and all package code  # Good coverage! 93% is fine.
    in general. 93% of code lines are covered by test cases.

    R/readODS.R:31:NA
    R/readODS.R:32:NA
    R/readODS.R:44:NA
    R/readODS.R:47:NA
    R/readODS.R:93:NA
    ... and 9 more lines

  ✖ omit "Date" in DESCRIPTION. It is not required and it
    gets invalid quite often. A build date will be added to the package
    when you perform `R CMD build` on it.
  ✖ add a "URL" field to DESCRIPTION. It helps users find
    information about your package online. If your package does not
    have a homepage, add an URL to GitHub, or the CRAN package package
    page.
  ✖ add a "BugReports" field to DESCRIPTION, and point it to
    a bug tracker. Many online code hosting services provide bug
    trackers for free, https://github.com, https://gitlab.com, etc.
  ✖ use '<-' for assignment instead of '='. '<-' is the
    standard, and R users and developers are used it and it is easier
    to read your code for them if you use '<-'.

    tests/testthat/test_legacy.R:16:9
    tests/testthat/test_legacy.R:21:9
    tests/testthat/test_legacy.R:24:9
    tests/testthat/test_legacy.R:26:9
    tests/testthat/test_legacy.R:28:9
    ... and 21 more lines

  ✖ avoid long code lines, it is bad for readability. Also,        # Some long lines are OK. In a few cases here they're indicative of a place where a utility functions might make nested code more readable .
    many people prefer editor windows that are about 80 characters
    wide. Try make your lines shorter than 80 characters

    R/readODS.R:28:1
    R/readODS.R:60:1
    R/readODS.R:66:1
    R/readODS.R:75:1
    R/readODS.R:76:1
    ... and 85 more lines

  ✖ avoid calling setwd(), it changes the global environment.
    If you need it, consider using on.exit() to restore the working   # You do! so this is fine.
    directory.

    R/writeODS.R:48:13
    R/writeODS.R:49:5
    R/writeODS.R:51:5

  ✖ avoid sapply(), it is not type safe. It might return a
    vector, or a list, depending on the input data. Consider using
    vapply() instead.

    R/readODS.R:153:26
    R/readODS.R:154:26
    R/readODS.R:184:24
    R/readODS.R:202:10
    R/readODS.R:310:12
    ... and 2 more lines

  ✖ avoid 1:length(...), 1:nrow(...), 1:ncol(...),
    1:NROW(...) and 1:NCOL(...) expressions. They are error prone and
    result 1:0 if the expression on the right hand side is zero. Use
    seq_len() or seq_along() instead.

    R/readODS.R:20:12
    R/readODS.R:143:88
    tests/testthat/test_write_ods_append_update.R:33:43
    tests/testthat/test_write_ods_append_update.R:34:40
    tests/testthat/test_write_ods_append_update.R:68:49
    ... and 2 more lines

─────────────────────────────────────

---

Reviewer 1: @emmamendelsohn
Reviewer 2: @adamhsparks
Due date: 2020-08-11

[noamross]

Thanks @emmamendelsohn and @adamhsparks for agreeing to review! Due date: 2020-08-11.

[adamhsparks]

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• As the reviewer I confirm that there are no conflicts of interest for me to review this work

Documentation

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README
• Installation instructions: for the development version of package and any non-standard dependencies in README
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

For packages co-submitting to JOSS

• The package has an obvious research application according to JOSS's definition

The package contains a paper.md matching JOSS's requirements with:

• A short summary describing the high-level functionality of the software
• Authors: A list of authors with their affiliations
• A statement of need clearly stating problems the software is designed to solve and its target audience.
• References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

• The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 5

• Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

---

Review Comments

It's good to see the ODS format getting some attention like MS Excel's proprietary formats in R.
While ODS files may not be used as much, I still think it's important to support this file format.

I appreciate the simplicity of the package. It does two things and it does them well. A good UNIX philosophy. This will help keep the package maintainable into the future and help rio maintenance as well, I'm sure.

There are some areas that need to be addressed before it can be accepted into rOpenSci's software community though.

Following are my comments on what I'd like to see changed and what needs to be fixed for inclusion.

Documentation

Vignettes

• I would state that PlantGrowth dataset comes from datasets before illustrating how to use it to help new users that aren't familiar with R and the available resources

• For clarity, please specify that the command, write_ods(Plant_Growth, "plant.ods") will write the file in the current working directory of the user's session.

Function Documentation (and Other)

• I would suggest to include a package level help file. usethis::use_package_doc() is a handy way to autogenerate the package-level documentation using details from the DESCRIPTION file.

• Please include examples for use in the helpfile documentation for read_ods() and write_ods().

• E-mail addresses in ROxygen should use a double @ sign, e.g. chainsawtiney@@gmail.com.
  Please refer to http://r-pkgs.had.co.nz/man.html, "Roxygen comments".

• Line 85 of writeODS.R, while technically correct, is unclear, especially for unfamiliar users. I'd suggest something like "An ODS file written to the file path location specified by the user."
  Or something along those lines to be clear what the return value is in plain English.

• Formatting the ROxygen comments properly will crosslink the HTML documentation, e.g. formatting "readr::type_convert" as readr::type_convert() on line 227 of readODS.R, will do this since you have set Roxygen: list(markdown = TRUE) in the DESCRIPTION file

• write_ods() has a parameter, overwrite, I think you mean to use "deprecated" in place of "depreciated" in the documentation? This also appears on line 89 in readODS.R as "depreciated" instead of "deprecated".

• For the parameters in write_ods() that take a TRUE/FALSE value, I'd like to see the default value to be explicitly stated here in the documentation.

• Titles should be capitalised, "\title sections should be capitalized and not end in a period.", from https://developer.r-project.org/Rds.html.

Community Guidelines

• The DESCRIPTION file lacks a 'BugReports' field. Most commonly this would point to https://github.com/chainsawriot/readODS/issues.

• The contributing guidelines are missing either in CONTRIBUTING or in the README.

General Comments on Code

• Check the output of goodpractice::gp() on the use of sapply() and 1:length() in functions to make the code more robust.

• When checking the documentation, I relieved a warning message, Warning message: roxygen2 requires Encoding: UTF-8. Inserting Encoding: UTF-8 in DESCRIPTION fixes the issue.

• The path parameter from read_ods() takes a default NULL value, but this is never checked. If the user does not supply a sheet to read the error message simply says, Error in .parse_ods_file(file) : object 'path' not found. This is honestly the most "base R" way of handling things I can think of. But I also think it's rather confusing to new users. This could be improved by a simple check to see if path is NULL before proceeding further when the function is executed. A more helpful message for the user would be desirable in this case as well, e.g. No file path was provided for the 'path' argument. Please provide a path to a file to import. or something of this nature to help guide the user.

• I'm unclear on the functionality of the function on line 47 in writeODS.R.

  .make_temp_dir <- function() {
      tmp <- tempfile()
      dir.create(tmp)
      return (tmp)
  }

Would it not be more simple to just use the tempdir() command here and work in that temp directory for the zipping process? This is how I coded this functionality in the GSODR package to unzip files.

• Consider using call. = FALSE in stop() functions throughout to provide a cleaner message to end-users.

Functionality

Installation

Installs as expected with no issues.

Functionality

• Imports files and writes ODS files as advertised.

• Compared with readxl::read_excel() it results in the exact same data.frame() in R.

Performance

• Performance is notably slower for the same data than readxl::read_excel(), but considering that read_ods() is written in R while the other is C, it makes sense and this isn't designed for speed (nor advertised for it either).

Automated Tests

• 93% coverage is very good, most of the missing lines aren't easily covered and/or are related to stop() messages.

Packaging Guidelines

• The assignment operators are not consistent between the functional code and the tests. The functions use <- while the tests use =. Per rOpenSci guidelines, either is acceptable, but you should be consistent in the use of them in the package.

• Currently the package is only checked via CI on Travis for Linux. Using GitHub Actions and the examples from r-lib/actions, it's rather easy to set up a full check of all three major OSes and various R versions effectively. rOpenSci guidelines require that packages are tested against the latest, previous and development versions of R.

[emmamendelsohn]

Heads up I will have my review posted tomorrow!

[emmamendelsohn]

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

• Briefly describe any working relationship you have (had) with the package authors.
• As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README
• Installation instructions: for the development version of package and any non-standard dependencies in README
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests: Unit tests cover essential functions of the package
  and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

• The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 5

• Should the author(s) deem it appropriate, I agree to be acknowledged as a package reviewer ("rev" role) in the package DESCRIPTION file.

---

Review Comments

Well done--nice and simple! The code was easy to follow and review. I only have a few comments to add to what has already been mentioned.

Documentation

• Consider mentioning the list_ods_sheets() function in the vignette/README. I sometimes use readxl::excel_sheets(), so I imagine the equivalent would be useful for .ods users.

• Perhaps not worth mentioning in the vignettes, but the formula_as_formula argument in read_ods() would have been useful when I had to QA/QC spreadsheets in my previous job :)

• In documentation for read_ods(), I suggest clarifying that the na argument can be set to NULL, resulting in empty cells being treated as NA. And perhaps rephrase "Character vector of strings to use for missing values" to "Character vector of strings to be replaced as NA".

Functionality

• Check lines 92-98 in .parse_rows(). read_ods("starwars.ods", skip = 11) returns an empty data frame, when it should return the full data frame and a warning that the skip value is greater than the number of rows. The same happens when skip = 12. This is because in starwars.ods, the last two rows from parsed_sheets do not contain any values but are still counted toward length(rows), resulting in FALSE for the condition on line 92.

• Not required, but you may consider giving warnings for identical and missing column names. If the user were to convert the data.frame to a tibble, these naming issues will result in errors.