Open jennybc opened 1 year ago
Another argument for adding ...
to PKG_auth()
-like functions: there are already other arguments besides service_account
that one might want to pass, such as sub
. Will there be a slow trickle of such things and we'll be glad to have ...
?
Just to document if someone else is reading this, the current workaround for any situation like this is to call the credential fetcher directly with all necessary args and pass that token to PKG_auth(token =)
. So there's already a way to do this. This is about making it easier for a wrapper package user who probably doesn't want to know much about gargle.
Compare the typical signature of an auth function in an end-user package, like googledrive:
to the signature of
credentials_gce()
:If someone is not using the default service account, they need to specify
service_account
, butdrive_auth()
doesn't allow for that. One possible change is fordrive_auth()
-like functions to gain...
(probably right afteremail
) and pass that along totoken_fetch()
.Or a different approach is for
credentials_gce()
to look at...
and, ifemail
is present, use that asservice_account
.I haven't thought deeply on this, but wanted to record the thought.