Open LukasWallrich opened 1 year ago
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.
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.
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.
@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"
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."
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.]
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.
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
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 https://github.com/ESHackathon/CiteSource/issues/117#issuecomment-1603110815, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOK6NGNXFITYKWYSAT2AJFDXMSDNNANCNFSM6AAAAAAWVD76N4 . You are receiving this because you were mentioned.Message ID: @.***>
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?
First release:
usethis::use_cran_comments()
Title:
andDescription:
Authors@R:
includes a copyright holder (role 'cph')Prepare for release:
git pull
urlchecker::url_check()
devtools::check(remote = TRUE, manual = TRUE)
devtools::check_win_devel()
rhub::check_for_cran()
git push
Submit to CRAN:
usethis::use_version('minor')
devtools::submit_cran()
Wait for CRAN...
git push
usethis::use_github_release()
usethis::use_dev_version()
usethis::use_news_md()
git push