set up API key config file and a way to load it

[jeanetteclark]

Two steps here:

• create a blank config file with API keys
• set the package up to load the config file

Not sure if we should load the keys through a helper function or set the package up to load the file automatically

[MayaSamet]

Does the .Renviron solve this completely?

[mbjones]

Its best not to depend on specific .Renviron setups. Instead, use the options facility to retrieve credentials from the users environment like we do for the dataone package.

`

[jeanetteclark]

Hm. So are you thinking that a user can set the API token either via options(scopus_key = ...) or a user can add that line to their .Rprofile? The SCOPUS query function would then do something like SCOPUSKEY <- getOption("scopus_key") to retrieve it.

I do want to find a way to make it easy to not have to set it every time. Unlike dataone the keys don't expire, and they are somewhat difficult to track down on the SCOPUS website (at least compared to the Arctic Data Center), so retrieving one for every R session sounds annoying. That is why I was thinking of the .Renviron approach and setting it as an environment variable as opposed to an option.

Also: https://twitter.com/jennybryan/status/668908727852896256

[jeanetteclark]

Summary of slack discussion:

• API keys from these publishers are essentially never-expiring passwords, which would be best to not expose anywhere in plaintext
• keyring seems like a good way to store keys in either encrypted files or in the operating system's credential store

I got a keyring helper function set up scythe_set_key() as a wrapper around the keyring functions.

Disadvantages so far are:

• doesn't work well on RStudio Server. I have a pull request in for keyring to fix a bug so we have a workaround
• users have to unlock the scythe keyring interactively when they use functions by typing their keyring password into a prompt. This makes testing impossible as the tests are written currently, but we should be able to set up an encrypted file with keys for testing, I think. The above issue I put in a pull request for might affect this though

To dos:

• rewrite the readme with instructions for getting and setting API keys using the new method
• figure out how to get tests to run

[MayaSamet]

I can rewrite the readme

[mbjones]

For testing on Travis and related platforms, they have a facility for including encrypted keys to be used as secrets. See: https://docs.travis-ci.com/user/encryption-keys/ and https://cran.r-project.org/web/packages/httr/vignettes/secrets.html#travis Of course, Travis itself has access to those keys, so I wouldn't be pushing the nuclear football codes up there.

[jeanetteclark]

I switched to github actions, and have set up the two API keys as secrets in the repo. They are passed via environmental variables to the functions that need them by the config file. It is a bit of a backdoor route to the auth when we would prefer users to use keyring, but we can choose whether we document that or not

R CMD check is passing!