Best of Both Worlds

[jonthegeek]

You... weren't wrong about how to implement auth, now that I've dug deep into the bowels of httr2. In theory it would be better to use httr2::req_oauth_auth_code, which re-requests the data if it isn't available in a cache. EXCEPT they don't have a simple way built in to auto-switch that to use environment variables when they're available, and that's what we need to make this work smoothly on GHA.

I'm somewhat surprised this isn't built into httr2, but I'm PRETTY sure it isn't.

The general plan (and some general principles):

• .call_youtube_api will use settings and/or environment variable to figure out what to do. I think these will be explicit settings so it's visible.
• Each function that calls .call_youtube_api will inherit those settings.
• Defaults will aim to make the settings unnecessary to set. They'll really only be there for cases where (for example) people want to manually switch clients or something.
• We'll use req_oauth_auth_code (which automatically hits the browser for auth if necessary, and refreshes if available) if nothing tells us to do otherwise.
• We'll have an argument about whether to cache to disk, and prompt the user in interactive sessions.
• If we're given a token, we'll attempt to use it, falling back to req_oauth_auth_code if it fails.
• If we're given a refresh token, we'll try to use it before falling back.

I'll need an hour or so to work that out, but I think I grok the essentials. This will allow us to set things up to run fully automatically, even on GHA, as long as we occasionally manually refresh the refresh_token (although they don't seem to actually expire, unless the user revokes them).

[jonthegeek]

Note: I think we might be able to stack some of these things up, and then httr2 will do the fall-backs automatically. I'll experiment with that when I get back to this.

[jonthegeek]

Fixed in #2.