Is there a reason why Aws::Credentials is not a Aws::CredentialProvider?

[cervantn]

Is there any reason why Aws::Credentials does not include Aws::CredentialProvider, like other classes in the SDK (e.g. AssumeRoleCredentials) which implement the credential provider interface (implementing #credentials and set?)?

[alextwoods]

Its largely legacy - the credential providers use .credentials to return Aws::Credentials, so we don't want those credentials to also be a provider. However, we should have created a separate StaticCredentialProvider instead of adding a .credentials method to Aws::Credentials. Additionally, the set? method in Aws::CredentialProvider relies on calling the set? method of the returned credentials.

Do you have a use case for needing Aws::Credentials to include Aws::CredentialsProvider?

[cervantn]

Not any sort of critical use case. I was writing some unit tests recently for a utility which returns either an Aws::Credentials or Aws::CredentialProvider instance depending on its input (it's not really important how or why). But I was hoping that I could write a single RSpec assertion for all examples like:

it { is_expected.to be_an(Aws::CredentialsProvider) }

but this fails for the cases where an Aws::Credentials instance is returned instead. I was able to work around it with a custom matcher:

define :return_aws_sdk_credentials do
  match do |actual|
    actual.is_a?(Aws::CredentialProvider) || actual.is_a?(Aws::Credentials)
  end
end

...

it { is_expected.to return_aws_sdk_credentials }

but honestly I wish I didn't need to think about these cases differently. In all of the code which uses this utility, I don't need to think about it because I can call #credentials in either case. I also recognize that I could instead be doing a respond_to assertion, but I guess I'm just not a big fan of duck in unit tests.