Currently, this library sources credentials for performing operations exclusively from env. Although this is convenient most of the time, it introduces two problems:
Side effects, any consuming binary or library now needs to support and document these environment variables even if completely unrelated to its own config management
Unable to inject config/credentials into the library, meaning it's impossible to perform config gathering ONCE at the beginning of the app, and then pass relevant config to subsystems; note that this also makes it impossible to hot-load a new config into the binary consuming this lib, it must be completely terminated and restarted.
As it stands, the library config is self-contained within the ServiceAccount struct after loading from env. Allowing for optional passing in of this struct on creation of the client should solve this issue. All downstream code would need to be updated to use this optional config over the globally-defined crate::SERVICE_ACCOUNT however.
I believe that #73 would go a long way in resolving this, which I am hoping to merge soon. Is there something more you have in mind that what is being offered there?
Currently, this library sources credentials for performing operations exclusively from env. Although this is convenient most of the time, it introduces two problems:
As it stands, the library config is self-contained within the
ServiceAccount
struct after loading from env. Allowing for optional passing in of this struct on creation of the client should solve this issue. All downstream code would need to be updated to use this optional config over the globally-definedcrate::SERVICE_ACCOUNT
however.