Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rclean: A Tool for Writing Cleaner, More Transparent Code #327

Closed
1 of 8 tasks
MKLau opened this issue Jul 23, 2019 · 82 comments
Closed
1 of 8 tasks

Rclean: A Tool for Writing Cleaner, More Transparent Code #327

MKLau opened this issue Jul 23, 2019 · 82 comments

Comments

@MKLau
Copy link

MKLau commented Jul 23, 2019

Submitting Author: Matthew K. Lau (@MKLau)
Repository: https://github.com/MKLau/rclean


  • Paste the full DESCRIPTION file inside a code block below:
Type: Package
Package: Rclean
Title: A Tool for Writing Cleaner, More Transparent Code
Version: 1.1.0
Author: Matthew K. Lau
Maintainer: Matthew K. Lau <matthewklau@fas.harvard.edu>
Description: To create clearer, more concise code provides this
	     toolbox helps coders to isolate the essential parts of a
	     script that produces a chosen result, such as an object,
	     tables and figures written to disk and even warnings and
	     errors.
URL: https://github.com/ProvTools/Rclean
BugReports: https://github.com/ProvTools/Rclean/issues
License: GPL-3 | file LICENSE
Imports: igraph, jsonlite, formatR, CodeDepends, Rgraphviz, methods, knitr
Suggests: 
    roxygen2,
    testthat,
    covr
Language: en-US
Encoding: UTF-8
RoxygenNote: 6.1.1
VignetteBuilder: knitr

Scope

  • Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below.:

    • data retrieval
    • data extraction
    • database access
    • data munging
    • data deposition
    • reproducibility
    • geospatial data
    • text analysis
  • Explain how the and why the package falls under these categories (briefly, 1-2 sentences). Please note any areas you are unsure of:

In writing analytical scripts, software best practices are often a
lower priority than producing inferential results, leading to large,
complicated code bases that often need refactoring. The "code
cleaning" capabilities of the Rclean package provide a means to
rigorously identify the minimal code required to produce a given
result (e.g. object, table, plot, etc.), reducing the effort required
to create simpler, more transparent code that is easier to reproduce.

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

The target audience is domain scientists that have little to no formal
training in software engineering. Multiple studies on scientific
reproducibility have pointed to data and software availability as
limiting factors. This tool will provide an easy to use tool for
writing cleaner analytical code.

There are other packages that analyze the syntax and structure of
code, such as lintr, formatr and cleanr. Rclean, as far as we are
aware, is the only package written for R that uses a data provenance
approach to construct the interdependencies of objects and functions
and then uses graph analytics to rigorously determine the desired
pathways to determine the minimal code-base needed to generate an
result.

  • Any other questions or issues we should be aware of?:

Not that I can think of at the moment.

@MKLau MKLau changed the title *Rclean*: A Tool for Writing Cleaner, More Transparent Code Rclean: A Tool for Writing Cleaner, More Transparent Code Jul 23, 2019
@annakrystalli
Copy link
Contributor

Thanks for your submission @MKLau! I'll be handling your review. Stay tuned while I complete editors checks. I'll get back in touch when they are done.

@MKLau
Copy link
Author

MKLau commented Jul 24, 2019

Thanks!

@annakrystalli
Copy link
Contributor

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

Installation:

Hello again @MKLau 👋

I'm having issues installing the package. Although installing from CRAN works,
installing from GitHub using devtools::install_github("ProvTools/Rclean", ref = "dev") or from source locally does not, producing this error :

Downloading GitHub repo ProvTools/Rclean@master
Skipping 2 packages not available: CodeDepends, Rgraphviz
ERROR: dependency ‘CodeDepends’ is not available for package ‘Rclean’
* removing ‘/Library/Frameworks/R.framework/Versions/3.6/Resources/library/Rclean’
Error: Failed to install 'Rclean' from GitHub:
  (converted from warning) installation of package ‘/var/folders/8p/87cqdx2s34vfvcgh04l6z72w0000gn/T//Rtmp0mSvCy/filea469117a2725/Rclean_1.1.0.tar.gz’ had non-zero exit status

CodeDepends is on github so the remote repository needs to be includes in the DESCRIPTION file under Remotes.

So after adding:

Remotes:
    duncantl/CodeDepends

to DESCRIPTION, I now get a different install error:

Skipping 1 packages not available: Rgraphviz
Downloading GitHub repo duncantl/CodeDepends@master
Skipping 1 packages not available: graph
✔  checking for file ‘/private/var/folders/8p/87cqdx2s34vfvcgh04l6z72w0000gn/T/RtmperTpaE/remotesa03323bd0a21/duncantl-CodeDepends-7c9cf7e/DESCRIPTION’ ...
─  preparing ‘CodeDepends’:
✔  checking DESCRIPTION meta-information ...
─  installing the package to build vignettes
         -----------------------------------
   ERROR: dependency ‘graph’ is not available for package ‘CodeDepends’
─  removing ‘/private/var/folders/8p/87cqdx2s34vfvcgh04l6z72w0000gn/T/Rtmpoz9E5n/Rinsta2487ca40f8/CodeDepends’
         -----------------------------------
   ERROR: package installation failed

Both Rgraphviz & graph are bioconductor packages.

Adding:

biocViews:

just above Imports: in your DESCRIPTION file resolves the Rgraphviz issue but not the error generated for graph through attempted installation of CodeDepends. And trying to just install it on it's own with devtools::install_github("duncantl/CodeDepends") produces the same error. How did you manage to install CodeDepends?

I tried just adding graph as a dependency in your DESCRIPTION but that didn't resolve the CodeDepends error. It might be useful to get in touch with the package authors to see if they can help.


Finally, I also got these warnings:

✔  checking for file ‘/private/var/folders/8p/87cqdx2s34vfvcgh04l6z72w0000gn/T/Rtmpkh4rA9/remotes26657867070/ProvTools-Rclean-47ec758/DESCRIPTION’ ...
─  preparing ‘Rclean’:
✔  checking DESCRIPTION meta-information ...
─  checking for LF line-endings in source and make files and shell scripts
─  checking for empty or unneeded directories
─  looking to see if a ‘data/datalist’ file should be added
     NB: this package now depends on R (>= 3.5.0)
     WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/clean.simple.out.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/format.simple.out.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects: 'Rclean/tests/testthat/lib.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/libs.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects: 'Rclean/tests/testthat/opt.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects: 'Rclean/tests/testthat/pi.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/prov.g.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/prov.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/rp.clean.x.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/rp.clean.y.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/rp.clean.y.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects:  'Rclean/tests/testthat/rp.options.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects: 'Rclean/tests/testthat/s.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects: 'Rclean/tests/testthat/sp.test.rda'  WARNING: Added dependency on R >= 3.5.0 because serialized objects in  serialize/load version 3 cannot be read in older versions of R.  File(s) containing such objects: 'Rclean/tests/testthat/vl.test.rda'
─

Which suggest that you need to set a minimum version of R in DESCRIPTION. For more information see: r-lib/devtools#1912
Adding:

Depends:
   R (>= 3.5.0)

in your DESCRIPTION file indeed solves the problem.


So until these installation issues are resolved, I can't really proceed with the rest of the editors checks as they are all performed on the source code which needs to be able to be installed from source (ie not just downloading the binary from CRAN. For example, running devtools::check() just errors because of missing the CodeDepends package.

Just let me know when this problem is fixed and I can carry on with checks.


Reviewers:
Due date:

@MKLau
Copy link
Author

MKLau commented Aug 9, 2019

Hi @annakrystalli, thanks for your feedback on this. I've been looking into the issues with installing those dependencies.

The package installs from dev on github via devtools on my machine and on Travis' server. However, I manually installed the CodeDepends on my machine, and Travis manually installs as well. I haven't yet done a full install on a fresh machine just using devtools.

This is an important issue, as it would make install much easier to just run one command. So, I'll sort this out and let you know.

@MKLau
Copy link
Author

MKLau commented Aug 9, 2019

Hi @annakrystalli, alright, I did a fresh install of R on my machine with the addition of all your dependency fixes to the DESCRIPTION and I get a similar error as you:

> install_github("Provtools/Rclean", ref = "deps")
Downloading GitHub repo Provtools/Rclean@deps
Downloading GitHub repo duncantl/CodeDepends@master
Skipping 1 packages not available: graph
Installing 2 packages: graph, XML
Error: Failed to install 'Rclean' from GitHub:
  Failed to install 'CodeDepends' from GitHub:
  (converted from warning) package ‘graph’ is not available (for R version 3.6.1)

Travis still installs without error, which is installing the graph package separately.

I've done some searching on Stack Exchange, and I can see why RGraphviz would install but not graph. I'll keep searching for possible workarounds.

@MKLau
Copy link
Author

MKLau commented Aug 20, 2019

@annakrystalli

Hi Anna, I still haven’t found a solution to the graph package install other than manually installing graph via BiocManager. So, if you’d like you should be able to proceed by first installing graph before installing

install.packages(“devtools”)
install.packages(“BiocManager”)
BiocManager::install(“graph”)
devtools::install_github(“provtools/rclean”, ref = “dev”)

It looks like the CodeDepends maintainers are working on a solution for this (duncantl/CodeDepends#30) but currently they’re essentially using the manual install method like this.

I’m adding this approach to the dev branch install instructions but I’m dissatisfied with this as an install method. I’ll keep looking for a fix and follow the updates from the CodeDepends folks.

@annakrystalli
Copy link
Contributor

Hey @MKLau, sorry for slow reply, I am actually on holiday so will probably be slow getting back to you for the next week also. Apologies!

In the meantime, I found a short term workaround that hopefully we might be able to turn into a more long-term one.

I forked CodeDepends and just added biocViews: to the DESCRIPTION file in my fork: https://github.com/annakrystalli/CodeDepends.

I also changed the remote repository pointer in the Rclean DESCRIPTION to annakrystalli/CodeDepends to install my fork of the package and installation of RClean worked! ✨🎉. This setup installs version 1.62 of graph. Out of curiosity, what version do you have installed? I quickly ran the tests and they all passed so on the surface this version of graph seems to work with Rclean.

I'll make a pull request to the CodeDepends repo and hope they will merge it. But if not, you could just maintain a fork of CodeDepends that your package depends on where you include biocViews: in the DESCRIPTION. In fact, I would suggest that you make a fork, set it up as I did and use that as your dependency for now. That would allow both myself and reviewers to proceed with installing and reviewing the package. Then, if and once the PR is merged, you can revert back to the upstream CodeDepends repo.

Sound good?

@MKLau
Copy link
Author

MKLau commented Aug 28, 2019

Great, @annakrystalli! Copy that. I’ll use this workaround and follow what the CodeDepends issue you opened. Hopefully they just merge it in, which seems likely.

Enjoy the rest of your break!

@MKLau
Copy link
Author

MKLau commented Aug 28, 2019

Now completed, tested and merged into dev branch.

@annakrystalli
Copy link
Contributor

OK great and apologies for massive delay! Been pretty snowed under since I got back and still catching up. I've now been able to complete editors checks and installation worked fine with the new setup.

So, firstly and most importantly, I'd recommend that all your installs happen from the master branch and that this is always stable. Use your dev branch for the more experimental / development state of code.

The rest of the editors checks threw up only minor issues.

goodpractice

goodpractice::gp()

Throws a warning

  ✖ fix this R CMD check NOTE: Namespaces in Imports field not imported from: ‘BiocManager’ ‘knitr’ All declared Imports
    should be used.

I wonder, are there calls to functions in BiocManagers in your code? It's hard to search the dev branch of your repo so could figure it out without scanning all your R/ code (which I didn't do 😜).

spell_check

A few potential genuine typos

devtools::spell_check("/Users/Anna/Documents/workflows/rOpenSci/editorials/Rclean")
#>   WORD              FOUND IN
#> formate           p.spine.Rd:10
#> funcitons         codeGraph.Rd:16
#> inforrmation      get.libs.Rd:16
#> parantage         get.spine.Rd:16
#> Parenatage        p.spine.Rd:5
#> Prases            parse.graph.Rd:5
#> reltionships      parse.graph.Rd:6
#> reproduciblity    README.md:49
#>                   Rclean.rmd:41

Created on 2019-09-10 by the reprex package (v0.3.0)

package coverage

Great coverage overall! Is there are reason var.id.R and write.code.R have such low coverage though?

covr::package_coverage("/Users/Anna/Documents/workflows/rOpenSci/editorials/Rclean")
#> Rclean Coverage: 81.22%
#> R/var.id.R: 0.00%
#> R/write.code.R: 45.45%
#> R/var.lineage.R: 70.00%
#> R/p.spine.R: 72.73%
#> R/parse.graph.R: 81.82%
#> R/parse.info.R: 87.50%
#> R/clean.R: 91.67%
#> R/codeGraph.R: 100.00%
#> R/get.libs.R: 100.00%
#> R/get.spine.R: 100.00%
#> R/read.prov.R: 100.00%

Created on 2019-09-10 by the reprex package (v0.3.0)

@MKLau, all in all I'm happy to proceed with finding reviewers. If you could have a go at fixing these minor issues during that time, that would be great. For me the most important is to get the master branch up to date and use that as the stable version of your package that will be reviewed.

Could you please add the rOpenSci under review badge to your README?

[![](https://badges.ropensci.org/327_status.svg)](https://github.com/ropensci/software-review/issues/327)

Thanks again for your patience during the holidays!


Reviewers:
Due date:

@MKLau
Copy link
Author

MKLau commented Sep 11, 2019

Hi @annakrystalli, no worries! Hope you had a relaxing/restorative holiday.

  • dev and master branch usage: I had stopped moving master forward as so many changes were happening due to the ROpenSci and JOSS review. Travis is currently running checks on the following updates (see following items). I'll merge into master after those checks pass. However, CRAN will now be behind master. Do you recommend updating it or waiting for the ROpenSci review process to proceed?
  • goodpractice Imports: I had added BiocManager to Imports to deal with the installation of graph but I think that your suggested fixes to CodeDepends has made that vestigial. knitr is required for automatically building the vignette. I removed BiocManager entirely and added knitr under Suggests.
  • goodpractices spell_check: fixed all of those, funny how many times I've run spellcheck but typos keep popping up!
  • goodpracices package coverage: var.id has become a legacy function that I think may be useful in the future, so I haven't gotten rid of it, but I also haven't bothered to add unit tests. I've added an issue for that, and I'll add them when I next get a chance. write.code only has partial coverage because part of its functionality is copying to the clipboard, which I haven't figured out how to write tests for. If you (or maybe one of the reviewers) have a suggestion, I'd be happy to get the coverage on that function higher.
  • Add badge to README: done!

Thanks for the updates on this, and happy to see the review move forward.

@MKLau
Copy link
Author

MKLau commented Sep 11, 2019

@annakrystalli FYI - master is now up to date with dev (now v1.1.0). CRAN is still v1.0.0.

@annakrystalli
Copy link
Contributor

Great work @MKLau !

Regarding your comments:

dev and master branch usage: I had stopped moving master forward as so many changes were happening due to the ROpenSci and JOSS review. Travis is currently running checks on the following updates (see following items). I'll merge into master after those checks pass. However, CRAN will now be behind master. Do you recommend updating it or waiting for the ROpenSci review process to proceed?

You should treat the GitHub version of your code as the development version in general and it is absolutely fine for it to not reflect CRAN. The way you link your GitHub code version to the CRAN released it through tags which snapshot more formally the state of the repository upon release. After that you are free to continue developing on GitHub by adding .9000 to the end of your release version in the DESCRIPTION to indicate this is the development version of the software.

That is somewhat different to the use of branches. You still want the master branch in the repository to reflect the most stable state of the development code and it should generally be the go to outward facing version of the development source code. I think the chapter on releasing packages sort of discusses this but think instead about how in general we often see in READMEs instruction to download from CRAN or download the development version from GitHub which is generally the master branch. Does that make sense?

write.code only has partial coverage because part of its functionality is copying to the clipboard, which I haven't figured out how to write tests for. If you (or maybe one of the reviewers) have a suggestion, I'd be happy to get the coverage on that function higher.

My go-to strategy in these situations is to have a look at the tests in packages that use the feature I want to test. I initially thought of reprex and saw that that just calls clipr::write_clip(). So here's a link to the tests script for that function write_clip() 😃.

For all your other comments: ✨

@annakrystalli
Copy link
Contributor

Another minor thing I've just noted. In the DESCRIPTION file, we require that author details are captured using the Authors@R notation not character strings. More details in the relevant r packages chapter.

@MKLau
Copy link
Author

MKLau commented Sep 12, 2019

Great! Thanks for the pointers. Per these suggestions, I’ll go ahead and:

  • update the readme to point to master as the stable “beta” install
  • switch to using the Authors@R field
  • look into implementing that test per test_render

@annakrystalli
Copy link
Contributor

We have reviewers! 🥳

Many thanks again for agreeing to review @wlandau and @nevrome. See below for review data. Any questions, just reach out.


Reviewers: @wlandau @nevrome
Due date: 2019-10-21

@nevrome
Copy link
Member

nevrome commented Sep 25, 2019

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 (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).
For packages co-submitting to JOSS

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: 3

  • 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

A very interesting package to simplify R scripts. I really like the underlying idea and the main functions clean and write.code work well when applied to the example script example/simple_script.R. Good job, @MKLau! However, the usability of the package can be increased a bit more. Some suggestions in no particular order:

  • The function documentation is very brief at the moment. I don't think this necessarily a bad thing, but for some of the functions the lack of description and example code leaves me wondering, what the respective function is supposed to do. Please add some more descriptive text and example code for clean, codeGraph and write.code. I would like to see codeGraph mentioned in the README/vignette.
  • I would love to have an example script (maybe example/simple_script.R) as a package example dataset that allows to explore the functions without the need to provide/prepare an own script. An example script will also allow you to add meaningful example code for the functions.
  • Retrospective Provenance remained a mystery for me. The missing piece of the puzzle is how to generate the relevant json file. Maybe I just missed the crucial hint? I would prefer to see a more extensive explanation of this feature and how to use it in the README/vignette.
  • In the context of the Retrospective Provenance feature you use the option interface to access the content of the json file. I do not understand why this rather unusual solution is necessary. Why can't the rd parameter simply get the relevant character vector? Instead of options(prov.json = readLines("example/prov_micro.json")); clean(file = "example/micro.R", rp = TRUE) the interface could simply be clean(file = "example/micro.R", rp = readLines("example/prov_micro.json")) or even just the path clean(file = "example/micro.R", rp = "example/prov_micro.json"). Why did you decide against this?
  • When I tried to apply clean to some of my own scripts, I realized that all packages necessary to run this script have to be loaded in the current session. If this was not the case, then I got the error message Error in as.environment(pos): no item called "package:dplyr" on the search list. I got this message 10+ times for one of my more complex scripts before clean went through, until I loaded all the packages. This is a little bit tedious. Is there another way to implement package loading? Maybe the automagic package could help to automate that? If this is not possible or if you don't want to have an automatic solution, then I would at least ask you to catch the current error message and replace it with something more intelligible, e.g. "Package xyz has to be loaded to analyze this script.".
  • Internal functions do not need to be exported (e.g. parse.info, read.prov). Remove the @export tag for these functions and add the tags @keywords internal and @noRd.
  • The simple_script.R code appears many times in the package (in the directories test/, inst/, exec/, example/). I don't think you need this file so many times.
  • Although you not seem to work in RStudio I suggest to add a Rstudio project file in the root directory (+ the necessary additions to .Rbuildignore). That simplifies contributing for RStudio users.
  • You could add a help page for the whole package as described here. I often use this page as an entry point for the function index.
  • This might be way beyond the purpose of this review, but as I personally consider these kind of things when I decide whether I want to use a package, I would like to add that I was not able to access neither your homepage http://mklau.info/ nor the one the Github Orga ProvTools http://provtools.org/ [2019-09-24].
  • The JOSS paper manuscript seems to be in an unfinished state because several sections are mentioned with a keyword but not yet written. The text available so far is fine.
  • In the travis-ci setup I suggest to treat warnings as errors (warnings_are_errors: true). I think this is usual for R packages, because no package with warnings can go to CRAN.

@annakrystalli
Copy link
Contributor

Thanks for your speedy response @nevrome!

@MKLau, it's probably best to wait till both reviews are in and then respond.

@MKLau
Copy link
Author

MKLau commented Jan 7, 2020

Ah, thanks for catching that @wlandau. Must have been from a copy-paste. Will fix now!

@MKLau
Copy link
Author

MKLau commented Jan 7, 2020

Fixed and committed to master.

@wlandau
Copy link
Member

wlandau commented Jan 7, 2020

Confirmed, thanks.

You have addressed all my feedback, and Rclean has come a long way in a short time. As a reviewer, I approve Rclean for rOpenSci. Well done, @MKLau!

@annakrystalli
Copy link
Contributor

annakrystalli commented Jan 8, 2020 via email

@MKLau
Copy link
Author

MKLau commented Jan 8, 2020

Thanks @wlandau, and everyone else for the input/help!

@annakrystalli looking forward to it, but have a great rest of the holiday and get safely down off the mountain!

@annakrystalli
Copy link
Contributor

Approved! 🥳🙌

Thanks @MKLau for submitting and @wlandau and @nevrome for your reviews!

To-dos:

  • Transfer the repo to rOpenSci's "ropensci" GitHub organization under "Settings" in your repo. I have invited you to a team that should allow you to do so. You'll be made admin once you do.
  • Add the rOpenSci footer to the bottom of your README
    " [![ropensci_footer](https://ropensci.org/public_images/ropensci_footer.png)](https://ropensci.org)"
  • Fix all links to the GitHub repo to point to the repo under the ropensci organization.
  • If you already had a pkgdown website, fix its URL to point to https://docs.ropensci.org/package_name and deactivate the automatic deployment you might have set up, since it will not be built centrally like for all rOpenSci packages, see http://devdevguide.netlify.com/#docsropensci. In addition, in your DESCRIPTION file, include the docs link in the URL field alongside the link to the GitHub repository, e.g.: URL: https://docs.ropensci.org/foobar (website) https://github.com/ropensci/foobar
  • Add a mention of the review in DESCRIPTION via rodev::add_ro_desc().
  • Fix any links in badges for CI and coverage to point to the ropensci URL. We no longer transfer Appveyor projects to ropensci Appveyor account so after transfer of your repo to rOpenSci's "ropensci" GitHub organization the badge should be [![AppVeyor Build Status](https://ci.appveyor.com/api/projects/status/github/ropensci/pkgname?branch=master&svg=true)](https://ci.appveyor.com/project/individualaccount/pkgname).
  • We're starting to roll out software metadata files to all ropensci packages via the Codemeta initiative, see https://github.com/ropensci/codemetar/#codemetar for how to include it in your package, after installing the package - should be easy as running codemetar::write_codemeta() in the root of your package.

For submission to JOSS

  • Activate Zenodo watching the repo
  • Tag and create a release so as to create a Zenodo version and DOI
  • Submit to JOSS at https://joss.theoj.org/papers/new, using the rOpenSci GitHub repo URL. When a JOSS "PRE REVIEW" issue is generated for your paper, add the comment: This package has been reviewed by rOpenSci: https://LINK.TO/THE/REVIEW/ISSUE, @ropensci/editors
    Ping me here when you are ready to proceed with this if you want me to have a quick look at the updated paper.md

Should you want to acknowledge your reviewers in your package DESCRIPTION, you can do so by making them "rev"-type contributors in the Authors@R field (with their consent). More info on this here.

Welcome aboard! We'd love to host a blog post about your package - either a short introduction to it with one example or a longer post with some narrative about its development or something you learned, and an example of its use. If you are interested, review the instructions, and tag @stefaniebutland in your reply. She will get in touch about timing and can answer any questions.

We've put together an online book with our best practice and tips, this chapter starts the 3d section that's about guidance for after onboarding. Please tell us what could be improved, the corresponding repo is here.

@danielskatz
Copy link

Note that this is already under review by JOSS, and that review has been paused while the rOpenSci has proceeded. Once this rOpenSci process is complete, the JOSS review can restart, and should be fast.

@MKLau
Copy link
Author

MKLau commented Jan 9, 2020

Great, thanks Anna (@annakrystalli), will get on those ASAP.

Also, thanks @danielskatz for keeping the manuscript in a holding pattern. It has been greatly improved via the software review. Looking forward to getting it finished.

@stefaniebutland
Copy link
Member

Congratulations @MKLau on passing review, and your pending JOSS publication. Would you be interested in writing a Tech Note for rOpenSci about your package? Anna suggests that it is an "interesting package that could really simplify creating reproducible examples and pairing down code to the essentials for producing a given output."

Tech Notes are written for an audience that wants details and should provide something a reader could not glean from the documentation itself.

If interested, after JOSS publication is probably best timing, so you could respond then. Instructions are here: https://github.com/ropensci/roweb2#contributing-a-blog-post. Typically you would submit a draft by pull request, I review, and we can publish within a week.

@MKLau
Copy link
Author

MKLau commented Jan 13, 2020

Thanks, @stefaniebutland, I have read a number of the Tech Notes you’ve helped to put out, and I’ve always have found them to be engaging and useful. I’m definitely interested and I’ll keep it in mind as the manuscript is in review.

@MKLau
Copy link
Author

MKLau commented Feb 10, 2020

Hi @annakrystalli, Almost done with the transfer to ROS and edits on the JOSS manuscript. Github has been throwing a slow Unicorn! message whenever I try and create a pull request now that Rclean has moved to ROpenSci. Will try again tomorrow to merge the new changes that have updates to Travis and Codecov.

A couple questions:

  • There is a message at https://docs.ropensci.org/rodev/reference/add_ro_desc.html that says "No longer recommended!" Should I still add this per your instructions or is there a new method?
  • Do you have a moment to look over the manuscript (see Rclean/joss/paper.Rmd)? If not no worries. I'll pass it along to the JOSS reviewers once I get it linked up to Zenodo correctly.

Thanks!

Matt

@annakrystalli
Copy link
Contributor

Hello @MKLau ! I've just transferred full admin rights back to you so you should have full control of the repo again.

The paper looks good to me! I wonder if you should show loading the library? Otherwised I reckon it's good to go.

And yes well spotted, please ignore initial instruction to add_ro_desc()

@MKLau
Copy link
Author

MKLau commented Feb 11, 2020

Thanks for looking over the paper, @annakrystalli . I'll go ahead and add a line showing library("Rclean").

One more question, how do I enable Zenodo watching? I don't see it when I access Zenodo. Should I have done this prior to transferring the repo to ROpenSci?

Also, I keep getting a long loading time page.

image

Do you have access to the repo? Would you be able to check if you can open a new pull request?

@MKLau
Copy link
Author

MKLau commented Feb 12, 2020

@annakrystalli

  • I'm still getting this slow loading message when I try to setup a pull request, so I just bypassed it and did a manual merge and push.
  • Also, looks as though my previous Zenodo setup automatically switched from MKLau to ROpenSci. So, good to go.

I'm going to go ahead and send to JOSS. Let me know if you get a chance to look at the pull request initiation from your end though.

annakrystalli added a commit to annakrystalli/Rclean that referenced this issue Feb 13, 2020
@annakrystalli
Copy link
Contributor

Hi @MKLau, just looking into the pull request issues you're having. I've managed to make a successful PR (not merged). ropensci-archive/Rclean#201

When and where exactly are you getting the slow unicorn message?

@MKLau
Copy link
Author

MKLau commented Feb 13, 2020

Ah, looks like it's resolved now! I can see your pull request.

It was throwing the slow unicorn every time I tried to go to view the pull request. Maybe it had something to do with the transfer from my personal profile to the ROS org.

@annakrystalli
Copy link
Contributor

Good to hear it's all working now! I take it you are in the process of completing with JOSS too right? I'm going to go ahead and close this issue now.

@MKLau
Copy link
Author

MKLau commented Feb 13, 2020

@annakrystalli yes it's now underway (again). Thanks again for all your help!

@stefaniebutland
Copy link
Member

Congratulations on your JOSS publication @MKLau. We would love to have a technote about Rclean as noted above

Anna suggests that it is an "interesting package that could really simplify creating reproducible examples and pairing down code to the essentials for producing a given output.

We now have more detailed guidance: https://blogguide.ropensci.org/

If you're interested, please suggest a date for submission and I can provide a publication date.

@MKLau
Copy link
Author

MKLau commented Mar 3, 2020

Hi @stefaniebutland, yes, we would be interested in publishing a technote with an announcement of the package. I am currently in a grant writing period but would be able to write something up next week. Would that time frame work?

@stefaniebutland
Copy link
Member

Yes it would thank you. Please submit when you're ready using tentative publication date 2020-03-17.

cc @ropensci/blog-editors

@MKLau
Copy link
Author

MKLau commented Mar 3, 2020

@stefaniebutland

Great, sounds good.

@MKLau
Copy link
Author

MKLau commented Mar 13, 2020

Hi @stefaniebutland,

Just finished with proof reading and spellcheck of the technote. You can find it here: https://github.com/ropensci/Rclean/blob/technote/ropensci/rclean_technote.md

The associated Rmd file is in the same directory on that branch too, if you need to have a look.

I’ve written it as an expanded version of the JOSS article, with a bit more discussion of a few details. Happy to have any edits and/or suggestions though.

Thanks and hope you’re healthy and well.

@steffilazerte
Copy link
Member

steffilazerte commented Mar 13, 2020

Hi @MKLau, I've been chatting with @stefaniebutland and we were thinking that your article looks a bit more like a blog post than a tech note (particularly the section talking about the Provenance Engine). This is great!

To get this published, I invite you to submit it as a pull request to the roweb2 repository.
You can see the full instructions for setting it up in roweb2 in the Blog Guide, particularly the chapter on Technical Guidelines. If you agree with our assessment of a blog post, rather than tech note, just follow the set up for blog post.

I'll be your friendly reviewer and will be ready to review on Monday, if you can open the pull request by then. Once you're ready for review, either let me know in a comment on the pull request or change the pull request from Draft to Non-Draft.

Thanks!

@MKLau
Copy link
Author

MKLau commented Mar 13, 2020

Hi @steffilazerte, thanks for enlisting to review! Happy to go either way. If this seems more like a blog post to you two, I'm fine with that. I'll read up on roweb2 and I'll aim to submit before Monday morning.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants