Open joeroe opened 5 years ago
Yes, that's pretty much it, I just did a R CMD check on Linux and the main thing is this NOTE
N checking dependencies in R code (939ms)
Unexported objects imported by ':::' calls:
‘usethis:::done’ ‘usethis:::field’ ‘usethis:::git_uncommitted’
‘usethis:::todo’ ‘usethis:::value’
See the note in ?`:::` about the use of this operator.
I agree with @nevrome that we should just duplicate these functions in here, they are pretty simple and stable.
We are also having a discussion about the default behaviours, whether it makes sense in most cases to produce a /R
, /man
and NAMESPACE. I think we should consider an argument like
package = c('basic', 'full')where basic just gives a DESCRIPTION and full gives the usual stuff. I think most people are not going to be using
/R,
/manand
NAMESPACE at all. I usually delete them. So I think that default makes more sense than our current default. But it might be good to have some discussion about this before submitting to CRAN.
Thoughts welcome!
On my setup the package fails to build if there's no NAMESPACE
file, so that seems essential? I do use man/
and R/
(a big reason for using packages is to have documented and exported functions, no?), but presumably anyone doing that will be familiar enough with package structure to know to recreate them. roxygen2 also automatically recreates NAMESPACE
and man/
.
CRAN release is a good idea. It could be timed for the CAA2020 meeting. What comes to mind:
package = c('basic', 'full')
option is a good idea. The default does not have to include R/ and man/. The NAMESPACE file though is necessary as pointed out by @joeroe. BMFor the future
use_compedium()
Let's aim for rOpenSci review and onboarding, then CRAN, then JOSS paper
@nevrome Just want to check with you about what I did in #102. I think it makes sense to check if a directory exists or not. But the workflow gets a bit tangled up if a user does 'New project on GitHub first, then download to RStudio' and then runs use_compendium("pkgname")
. Because they may have made a readme file on GitHub or added other things there, then we want to overwrite them with use_compendium.
I did have this experience with a novice student recently who faithfully followed the steps in 'Happy Git With R' to create and clone a repo, but then got confused when using our functions because they did some things on their GitHub repo that we didn't anticipate (checked some boxes on the GitHub web page, etc).
My impression is that there are so many ways things can go wrong with having both of those Git/GitHub options for novices and in workshop situations, and it will be simplest for us to update the readme to limit the universe of possible confusions for the novice user, rather than trying to write code to catch all of the possible edge cases and handle them.
So I propose that we:
Create a Git managed directory linked to an online repository
to the step after 'rrtools::use_compendium("pkgname")'
Create a Git managed directory linked to an online repository
section, make "New project in RStudio first, then connect to GitHub/GitLab" the recommended option, and recommend advanced use only the "New project on GitHub first, then download to RStudio" option, or omit it altogether. I think my preference it to omit it from the readme, or just hide it away with something like "there are many possible ways to connect your compendium with Git and Github (see ...)" While we're discussing the instructions, I'll mention my proposal to combine usethis::use_mit_license(name = "My Name")
into use_compendium
. As always, I look forward to your thoughts and wisdom on these topics.
Well - #102 broke the suggested workflow, Ben. The check if the directory exists prevents the suggested pipeline of first cloning an empty repo from Github altogether.
This workflow was born from my workshop experience and I still prefer it that way round. Connecting an existing repo to Github later is a lot more awkward that starting from Github with a clean slate.
I suggest the following solution: If the selected directory exists and has files in it, then we ask the user two (!) times if he really likes to use this directory for the research compendium. If he agrees, then we unlink all files in the directory and go from there. Of course we have to make it really clear what that entails: Possibly the irretrievable loss of these files. We should list the files and ask with these nice three-options questions that force you to think about your decision.
Although installing from GitHub using devtools works fine, it would be mildly more convenient, and more familiar to newer R users, to install it the standard way from CRAN. This package seems fairly mature, is a CRAN release planned?
Scanning through issues I can find one that would hold up a CRAN release:
Any others?