search

uncoast-unconf / uu-2019-day-zero

Planning for day-zero training and whatnot
https://uncoast-unconf.github.io/uu-2019-day-zero
MIT License
6 stars 4 forks source link

usethis discussion #5

Open ijlyttle opened 5 years ago

ijlyttle commented 5 years ago

Hi,

The motivation for this issue is that there is a lot of usethis functionality that looks to be thisclose to being very useful for our one-day workshop. I hope that it's OK that I "use this" issue as a clearing house, because it might cut across different usethis issues, and also because it might be easier to discuss in a "quieter" context. Thus, I tag in @jennybc and @cderv, with the expectation that we will follow Jenny's lead on if/when any of this discussion should be moved to usethis.

It should go without saying that I will be happy to work on the solutions, not only to discuss the issues.

My initial purpose is to see if I understand where things stand today, using:

remotes::install_github("r-lib/usethis", ref = "15d1587")

First-and-foremost, I want to draw attention to the git_sitrep() function that, I think, is exactly what we are looking-for to answer our "are you ready to git(hub)" question:

# assess git
library("usethis")
library("withr")

# run from my home directory, not a git-directory
with_dir("~", {
  git_sitrep()
})
#> User
#> * Name: 'Ian Lyttle'
#> * Email: 'ian.lyttle@schneider-electric.com'
#> * Protocol: <unset>
#> * Has SSH keys: TRUE
#> * Vaccinated: TRUE
#> git2r
#> * Supports SSH: FALSE
#> GitHub
#> * User: 'ijlyttle'
#> * Name: 'Ian Lyttle'

Created on 2019-03-13 by the reprex package (v0.2.1)

If I understand correctly, the various sections tell me:

To be clear, I can't see any issues with git_sitrep(), I just wanted to put a spotlight on it.

There is a new family of functions for pull-requests, developed with both the contributor and maintainer in mind. Jenny tells me that the usethis team is (quite understandably) enthused about these functions. Among the many issues it aims to help us avoid is the "PR-from-master" problem.

Once things are well and truly working, I think that they could be very valuable to our discussions on collaboration and GH etiquette. I have not had a chance to really try them yet because I think I have run into a dilemma.

As you know, we can access a git remote using either https or ssh. In my particular case, I prefer ssh because it makes it easier for me to work with both public GitHub and GitHub Enterprise. For our purposes, however, https may be more suitable.

As I understand it, the pr_*() family does not yet support https; this is a current effort (usethis PR 632, not linking properly to remain stealthy).

Here's where I come back to SSH from earlier. Again, well known to the usethis team, but git2r has some difficulties to work with SSH credentials. In my case, git_sitrep() tells me that it can find my SSH keys, but that git2r cannot support SSH).

This is one of the reasons that Jenny was so pleased to see the release of the new credentials package, now on CRAN. Earlier this year, Jenny had indicated to me that the credentials package was/is planned to be the answer to usethis' credentials frustrations.

I think that if either one of these difficulties is lifted, we have a very useful set of tools to help us with teaching git(hub) collaboration.

Thanks for reading this far!

I'd like to ask a couple of questions:

Thanks!

jennybc commented 5 years ago

All looks good / accurate to me! Sometimes just installing git2r as a source package, still from CRAN, helps with this "supports SSH" thing @ijlyttle. My experience of that is more on macOS, though. But it is worth a shot. But yes this is why I often recommend HTTPS in these settings.

I am working on git credential and protocol management right now and will have another PR up soon. This will then lead, in short order, to the pr_*() functions working with HTTPS.

ijlyttle commented 5 years ago

🎉🎉

Thanks, @jennybc! Looking forward to trying out the pr_*() functions!

Using macOS:

install.packages("git2r", type = "source")

then:

# assess git
library("usethis")
library("withr")

# run from my home directory, not a git-directory
with_dir("~", {
  git_sitrep()
})
#> User
#> * Name: 'Ian Lyttle'
#> * Email: 'ian.lyttle@schneider-electric.com'
#> * Protocol: <unset>
#> * Has SSH keys: TRUE
#> * Vaccinated: TRUE
#> git2r
#> * Supports SSH: TRUE
#> GitHub
#> * User: 'ijlyttle'
#> * Name: 'Ian Lyttle'

Created on 2019-03-13 by the reprex package (v0.2.1)

nikdata commented 5 years ago

Our company has a GitHub Enterprise service and I wanted to be able to balance both my work git repos (GitHub Enterprise) and my personal (GitHub) in the .Renviron file. Is it possible to have 2 (or more) PATs defined and then let RStudio know which token to use depending on where the repo is hosted (GitHub Enterprise vs. GitHub)? I'm not sure if I've articulated my use case very well - please let me know if I need to clarify.

ijlyttle commented 5 years ago

Hi @nikdata,

I have been thinking a little bit about this, and will be happy to discuss more at the unconf. I apologize for the brain-dump, but your question made me think that I need to just get my thoughts out for now.

My immediate focus is getting through day-zero 😅, and I've been very appreciative of @jennybc's efforts to get all this great new stuff on CRAN in time for our Unconf!

I think there are paths to customize the usethis-goodness for GitHub Enterprise, but it will take the buy-in of the usethis community. Maybe the time between now and the next CRAN release (to coincide with UseR in July, or so I've heard) is a good time to re-open that discussion; we had a bit of a discussion that we decided to postpone.

I may be oversimplifying and missing things, but in https world, there are two operative pieces of information:

Today, these are passed into functions like usethis::create_from_github(); the important thing is that this function has those arguments, with defaults set for public GitHub. Then, you can write a function for an institution, create_from_github_acme(), that wraps create_from_github() using Acme-specific defaults. This is the approach I had prototyped in ghentr.

The usethis::git_sitrep() function does not provide these arguments (today, we are thankful to have this available for public GitHub). To adapt, git_sitrep() would either need to provide the arguments or use environment variables, which it does for the PAT.

The more I think about it, the more I like the environment-variable approach. Let's say that git_sitrep() used the environment variables GITHUB_HOST and GITHUB_PAT (it uses GITHUB_PAT today). If GITHUB_HOST is not defined, then it would use public GitHub.

(My apologies for not knowing exactly how the host is managed today)

The institution-specific function could do something like this:

git_sitrep_acme <- function() {

  gh_local <- list(
    GITHUB_HOST = "https://github.acme.com/api/v3",
    GITHUB_PAT = Sys.getenv(GITHUB_PAT_ACME)
  )

  withr::with_envvar(gh_local, usethis::git_sitrep())
}

Anyhow, this is just a brain-dump for now, and I should try to find some time soon to engage the discussion at usethis.

jennybc commented 5 years ago

Yeah, I'd be happy to discuss ways to be more open to hosts other than GitHub.com. So GHE is the primary example, but we are also slightly uneasy with the heavy focus on GitHub vs. GitLab or whatever. But usethis is also very much a tool we keep in tip-top shape for our current workflow, which is GitHub.com-based. The constant tension is between helping the community and not taking on maintenance of features that aren't heavily used or that aren't used by our team at all.

When we can't absorb something into usethis, I hope we can tweak usethis's design so that extension to these other use cases is easy for the people who need it.