Release CiteSource 0.1.0 (CRAN checklist)

[LukasWallrich]

First release:

• usethis::use_cran_comments()
• Update (aspirational) install instructions in README
• Proofread Title: and Description:
• Check that all exported functions have @return and @examples #125
• Check that Authors@R: includes a copyright holder (role 'cph')
• Check licensing of included files
• Review https://github.com/DavisVaughan/extrachecks

Prepare for release:

• git pull
• Check if any deprecation processes should be advanced, as described in Gradual deprecation
• urlchecker::url_check()
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel()
• rhub::check_for_cran()
• git push
• Draft blog post

Submit to CRAN:

• usethis::use_version('minor')
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• git push
• usethis::use_github_release()
• usethis::use_dev_version()
• usethis::use_news_md()
• git push
• Finish blog post
• Tweet
• Add link to blog post in pkgdown news menu

[TNRiley]

need to tag up on the @examples - also the "cph" doesn't seem necessary and isn't on a number of other package descriptions, is this necessary with GPL licensing? If so I'd say add to all authors.

[TNRiley]

I've been exploring a few other packages that I'm familiar with and it looks like the add the @examples into inst/examples/
and name the script the same as the one in the R folder that they are linking. Not sure what the best practice is.

[TNRiley]

reviewed a few packages that are GPL>=3 and no authors/creators/etc. are listed as "cph" so I'm guessing we can leave this off without an issue.

[TNRiley]

#86 and #125 need to be completed before the rest of the prep work can be done

[TNRiley]

@LukasWallrich @kaitlynhair @DrMattG - When running devtools::check(remote = TRUE, manual = TRUE) I get the following...
Strong dependencies not in mainstream repositories:
ASySD

need to look into this further, but I did run into this https://cran.r-project.org/web/packages/remotes/vignettes/dependencies.html
"When you submit your package to CRAN, all of its dependencies must also be available on CRAN"

[TNRiley]

There is also this https://cran.r-project.org/web/packages/policies.html

"Packages on which a CRAN package depends should be available from a mainstream repository: if any mentioned in ‘Suggests’ or ‘Enhances’ fields are not from such a repository, where to obtain them at a repository should be specified in an ‘Additional_repositories’ field of the DESCRIPTION file (as a comma-separated list of repository URLs) or for other means of access, described in the ‘Description’ field."

[LukasWallrich]

Yes, ASySD needs to make it to CRAN first - we cannot depend on it otherwise.

[We could 'fake it' by adding it to Suggests and then prompting the user to install it from GitHub on package load - that might get through the CRAN check, but is clearly not in the spirit of the policy as our package offers very few useful functions in the absence of ASySD.]

[TNRiley]

Yes, ASySD needs to make it to CRAN first - we cannot depend on it otherwise.

[We could 'fake it' by adding it to Suggests and then prompting the user to install it from GitHub on package load - that might get through the CRAN check, but is clearly not in the spirit of the policy as our package offers very few useful functions in the absence of ASySD.]

I've added it to Additional_repositories in the Description. I read "mainstream repository" to include github, so maybe that will suffice.

[TNRiley]

Found this example on stack overflow, the info there said that we could move it to suggests rather than imports. Here is an example of a package that does this.. https://github.com/geanders/hurricaneexposure/blob/master/DESCRIPTION

[LukasWallrich]

The package must work without any suggests dependencies - so we then need to use all calls to ASySD conditionally, alerting the user that they need to install Asysd (most users should never see that as they will usually install the suggests packages as well - but some may not, and CRAN won't for some tests)

…

On Thu, 22 Jun 2023, 20:13 Trevor Riley, ***@***.***> wrote: Found this example on stack overflow, the info there said that we could move it to suggests rather than imports. Here is an example of a package that does this.. https://github.com/geanders/hurricaneexposure/blob/master/DESCRIPTION — Reply to this email directly, view it on GitHub <#117 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOK6NGNXFITYKWYSAT2AJFDXMSDNNANCNFSM6AAAAAAWVD76N4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[TNRiley]

dang. ok. I'm not sure where this leaves us. @kaitlynhair not sure if this is something you have time for adding ASySD to CRAN right now, I think we've talked about this, but obviously, it's extra work. I'd be happy to help.

Just to brainstorm a couple of other ideas...

Is it at all possible to use the functions from ASySD within CiteSource, cite ASySD and note that ASySD is either not on CRAN or that it is currently being developed and there are plans to submit to CRAN. Once ASySD is on CRAN, we could just call the functions? A workaround, but not straightforward.

We also know that deduplication can be improved on some things such as #160, potentially revisiting similarity scores, etc. This seems like a bit more than I'd like to undertake right now though I would enjoy it. We've discussed this and it it seems like a bigger project to tackle, potentially with other folks at ESHackathon who may be interested. Kaitlyn's functions would serve as the backbone, but further refining of criteria could be integrated into CiteSource.

*I had never really payed attention to whether many of the tools I used (which have shiny apps) are on CRAN. Looking specifically at packages like litsearchr, bibfix, citationchaser, etc. I'm now realizing that none of them are on CRAN. Knowing this makes me feel ok that for now we are not on CRAN, but it also makes me concerned about the longevity of these tools... @DrMattG are there any ESHackathon projects that have gone to CRAN?