Closed cboettig closed 6 years ago
@jennybc bought this up too. To me, the big question is whether usethis should support template customisation/composition with files or with functions?
(But even then having create_from_repo(fork = TRUE)
seems like a useful place to start even if you do the rest of the setup with other usethis functions)
Maybe something like:
create_from_github <- function(repo, path = ".", fork = TRUE) {
}
create_from_github("hadley/ggplot2")
# would clone using github api
# then checkout using git2r
# would create ggplot2 directory in wd
LMK what you think of this first quick attempt.
Nice!
However, it doesn't seem to handle the case I am most interested in, where it could take a new name for the repo rather than creating a github fork, e.g., something like:
create_from_github("cboettig/template", destination = "cboettig/my-paper")
GitHub's forking buttons already make getting a copy of a repo with the same name as the parent easy, but getting a copy with a different name requires more git commands than can be done in RStudio git gui. (For instance, I wish my students could run: create_from_github("espm-157/climate-template", "espm-157/climate-student-name")
and thus all have a copy of that climate repo ready to go under their own name but still in the class organizational account, where the private repo is free. What do you think?
Also noticed a few minor issues:
gh
only returns permissions
if GITHUB_PAT
is set; otherwise the function will error with:
Error in !repo_info$permissions$push : invalid argument type
since it can get repo_info
but not permissions.
Second, looks like you use utils::browse()
to open the .Rproj
file if the user is using RStudio... guessing this does the right thing in the desktop but in RStudio-server this literally opens the .Rproj text file in the browser.
You could just do create_from_repo(fork = FALSE)
and then use_github()
.
Can you please file an new issues for the other bugs?
Sorry if I'm missing something obvious, but I don't think fork=FALSE
+ use_github()
does this. Neither function seems to have an option to specify a new name for the new repository to be created on github (or the org/user under which to create it). I think a destination
argument to create_from_repo
would serve this purpose for the fork=FALSE
case.
Current With create_from_repo("espm-157/climate-template", fork=FALSE)
, I appear to get the same thing as if I just cloned the template: a local copy whose origin is still pointing to the original template. Then use_github()
just tells me GitHub is already initialized.
Will open other issues for the minor things, thanks!
Ooooh, use_github()
probably needs some option to switch repos. Would you mind filing an issue about that? It feels like that behaviour should be part of use_github()
first, and then integrated into create_from_repo()
.
usethis has great utilities for setting up a vanilla template using
create_package()
, along withuse_git()
,use_github()
, as @jennybc describes in https://community.rstudio.com/t/procedure-to-create-a-project-for-a-package-destined-for-github/2054/4.But this twitter thread got me thinking: often rather start with my own template: don't have to enter my name, choose my usual license, and other tweaks. Moreover, sometimes my template isn't a package, but a more minimal project repo; or maybe it's a specific template for some classroom assignment I want students to use.
It would be nice to have a function to deploy some existing template repo. e.g. this is basically what GitHub forking does, without creating the 'fork' connection, and allowing a new repo name. (Similar also to what GitHub Classroom does, but that's bound to a single organization destination).
I think this would be a straight-forward wrapper around existing
git2r
/ command-line git calls to rename the remote origin; possibly with agh
wrapper (or just single github API call via httr to avoid the dependency?) to create the new repo on GitHub. I sketched a prototype of this here: https://github.com/cboettig/template/blob/master/R/template.R. Would be happy to send a PR if something along these lines makes sense, though no doubt theusethis
team could manage a more robust implementation more efficiently anyhow, if it's worth doing.Thanks for your thoughts.