Update github_token.R to point Linux users to article

[rkb965]

usethis::create_github_token() returns code for calling gitcreds::gitcreds_set() to set credentials. This may not (does not?) work as a user would likely expect on Linux systems, as documented in the Managing Git(Hub) Credentials article as well as various issues. However, gitcreds::gitcreds_set() does not give any such indication, and I think a simple addition to the create_github_token() output would be valuable

git can be overwhelming, silent errors are extra challenging, the straightforward "Call `gitcreds::gitcreds_set() to register this token" sounds authoritative (leading to extra confusion when things don't work as expected), and {usethis} is such an excellent resource for getting people up and running with git. Thus, explicitly telling Linux users that they may need to reference additional documentation would likely be valuable

thanks for considering!

[jennybc]

Can you fill in a few more details to make sure I follow/remember?

usethis::create_github_token() returns code for calling gitcreds::gitcreds_set() to set credentials. This may not (does not?) work as a user would likely expect on Linux systems ...

By "does not work", I assume you don't get an error. But you're finding that the credential is not persistent? I can't remember what the exact experience is.

And by linking to the article, I assume you're talking about the "store the PAT in .Renviron" approach?

I feel like the git credential situation has recently gotten better on linux, i.e. there is a new-ish practical option for getting the same persistence that macOS and Windows users have. So that might also be worth doing a bit of research on.

[jennybc]

I think I am thinking of Git Credential Manager:

https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git?platform=linux

Now, of course, the exact flow they describe there isn't a drop-in substitute for us, because we really need the PAT for GitHub API work. But I suspect there's a way to use GCM that does suit our purposes.

[rkb965]

Hi Jenny! Thank you so much for looking into this.

By "does not work", I assume you don't get an error. But you're finding that the credential is not persistent? I can't remember what the exact experience is.

Yes, that was exactly my experience (no error but not persisting). Apologies, I was attempting to avoid dumping too many words in the little PR but I didn't mean to leave out useful details!

FYI, you are talking with someone who understands git only superficially, and I rely heavily on {usethis} for both my own use and for proselytizing when trying to convert colleagues to version control. I can't speak deeply to any of this.

I got to my (mis?)understanding about not being able to use the git credential store method (rather than PAT in .Renviron) on my work's Linux server via some issues that are old and may very well be outdated. One of which was:

Is there a way to get gitcreds working on RStudio server (linux)?

Yes, on Linux you often don't have a proper credential store, especially on a server. In your case

gitcreds::gitcreds_list_helpers()
[1] "cache"

means that you are using the cache credential helper: https://git-scm.com/docs/git-credential-cache This credential helper stores the credentials in memory, so they are lost after a reboot. It also has a timeout, defaulting to 900 seconds. If you can use an .Renviron file on RStudio server, then it is probably simplest to set up the token as an environment variable in .Renviron. You can set GITHUB_PAT_GITHUB_COM or just GITHUB_PAT, and gitcreds (and thus usethis, etc.) still picks these up. Originally posted by @gaborcsardi in https://github.com/r-lib/gitcreds/issues/29#issuecomment-784870166

And then the {usethis} article on git credentials:

Using .Renviron as your primary PAT store is less secure and, if you can, it is safer to keep your PAT in the Git credential store and let packages that need it to discover it there upon first need. Linux users may still need to use the .Renviron method, since they don’t have easy access to OS-managed stores like the macOS Keychain or Windows Credential Manager.

New suggestion Given that GCM is both possible and rapidly evolving (thank you for sharing — I passed those details about GCM on Linux on to the engineer who manages our server), would it be possible to either check that gitcreds::gitcreds_list_helpers() does not return "cache" (and return a warning if so?) or suggest (in that interactive message) that the user does? I'm certainly not trying to move all of the information contained in the documentation into these functions, but given that these functions are such very nice helper functions for the git-intimidated among us, I think it might be within scope.

Thank you for considering!

[jennybc]

Picking this back up after a long hiatus.

Relevant thread in gitcreds that Linux users may want to follow: https://github.com/r-lib/gitcreds/issues/47

I'm just going to do something minimal here in usethis, tweaking this PR, presumably.