Submission: gitignore

[PMassicotte]

Submitting Author: Philippe Massicotte (@PMassicotte)
Repository: https://github.com/PMassicotte/gitignore
Version submitted: 0.1.0
Editor: @melvidoni
Reviewer 1: @maurolepore
Reviewer 2: @aedobbyn
Archive: TBD
Version accepted: TBD

---

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

Package: gitignore
Type: Package
Title: Create useful .gitignore files for your project
Version: 0.1.0.9000
Authors@R: c(person("Philippe", 
         "Massicotte", 
         email = "pmassicotte@hotmail.com",
         role = c("aut", "cre")))
Description: Simple interface to query gitignore.io to fetch gitignore templates that can be included in the .gitignore file. More than 450 templates are currently available.
URL: https://github.com/PMassicotte/gitignore
BugReports: https://github.com/PMassicotte/gitignore/issues
License: GPL-3
Encoding: UTF-8
LazyData: true
Imports: 
    purrr,
    curl,
    glue,
    jsonlite,
    crayon,
    clipr,
    clisymbols,
    here,
    xfun
RoxygenNote: 6.1.1
Suggests: 
    spelling,
    knitr,
    rmarkdown,
    testthat (>= 2.1.0),
    covr
Language: en-US
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
  • database access
  • data munging
  • data deposition
  • reproducibility
  • geospatial data
  • text analysis

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

Because it helps facilitate use of version control.

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

Anyone working with the git technology can use the package to automatically generate the .gitignore file.

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

None that I could find.

• 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.

Yes. See #299 (comment)

Technical checks

Confirm each of the following by checking the box. 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.
• 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 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.

[melvidoni]

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

Hello @PMassicotte! Thanks for submitting your package. These are the editor checks performed with goodpractice. Please take care of them. Please, address these before I can search for reviewers, or write a justification. Tag me when you are done, please!

── GP gitignore ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

It is good practice to

  ✖ write unit tests for all functions, and all package code in general. 84% of code lines are covered by test
    cases.

    R/gitignore_fetch_available_templates.R:17:NA
    R/gitignore_fetch_ignore_templates.R:50:NA
    R/gitignore_fetch_ignore_templates.R:51:NA
    R/gitignore_fetch_ignore_templates.R:55:NA
    R/gitignore_write_gitignore.R:10:NA
    ... and 1 more lines

  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor windows that are about 80
    characters wide. Try make your lines shorter than 80 characters

    R\gitignore_fetch_available_templates.R:13:1
    R\gitignore_fetch_ignore_templates.R:19:1
    R\gitignore_fetch_ignore_templates.R:40:1
    R\gitignore_fetch_ignore_templates.R:46:1
    R\gitignore_fetch_ignore_templates.R:51:1
    ... and 5 more lines

---

Reviewers: @maurolepore and @aedobbyn.
Due date: June 17th

[melvidoni]

Reviewers have been assigned: @maurolepore and @aedobbyn.
The reviews due date is June 17th.

[PMassicotte]

Thank you @melvidoni. I have fixed long lines and added more tests.

[aedobbyn]

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

• 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

Great idea for a package @PMassicotte and looks good to me so far! Code is succinct and readable.

A few initial thoughts:

Things to look into

• You've got a couple of checks that overlap with each other: here and here. Seems to work fine if a list of template names is supplied as long as you check that each individually is of type character (the whole template_name will of course be of type list).

• If copy_to_clipboard is false, gitignore is not returned to the console as it should be (according to the docs)

• I think you need an argument for .gitignore_file in gi_fetch_ignore_templates if you want people to be able to modify a .gitignore file that doesn't live at here::here() (and then pass that path to the gi_write_gitignore line). Also on this, I might change that argument to gitignore_file instead of .gitignore_file but either way is fine.

• The test for gi_fetch_available_templates is currently commented out. This function is used inside gi_fetch_ignore_templates so it's tested every time gi_fetch_ignore_templates is run, but an isolated test for just that function would also be good to have.

Good things

• Tested in R GUI, also works fine (sans the crayon coloring, as expected)

• Love the use of here, glue, and crayon; makes code very readable!

Things to consider

• The API returns gitignore results in alphabetical order. You may want to sort these based on the order supplied by the user.

• If the user's .gitignore file doesn't exist and append_gitignore is true, you might consider creating a .gitignore at here::here() and writing to it, possibly by prompting the user at the console to make sure they want to create and write a .gitignore

• You might consider shortening the function names to just list_available and fetch_template, or something to that effect

Random

• For @maurolepore: just a note that you'll need latest version of testthat for expect_invisible (line 10) in test-gitignore_fetch_ignore_templates.R (earlier versions of testthat don't have that function)

[PMassicotte]

Thank you very much! I will work on that.

[PMassicotte]

Dear @aedobbyn I have made all the changes you suggested except the one about the order supplied by the user. I am currently just using the API as is. The other option if so make 1 call for each template (using lapply) and then combine the results. However, this will create many calls to the API instead of just one. Happy to hear your recommendations!

[aedobbyn]

Looks good!

I agree it's best to make one call to the API instead of multiple. What you could do if you want to sort the results is to do a regex search for the language in between three ###s since those always signal the beginning of a new language template and sort based on that. You could even separate each language into an element of a list and return the list. But this is all super optional :)

Small thing I just noticed is that this line in the docs references an old, longer function name and doesn't include a link (\link{}) to that function's documentation, which I think is always useful.