-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add config argument to boto3 resource (closes #168) #325
Conversation
Ping? |
I will take a look at it this week. We definitely need a configuration functionality like this in the resource interface. I think accepting the |
Note that the description of this pull request above did explicitly discuss a problem with passing a client to the resource. May not block that idea, but it definitely points out how error prone it could be. |
Those were good points. Seems like there are a lot of edge cases in being able to pass in a client. I think sticking with the config is the right direction for now. |
I agree, 👍 to preferring configs over clients, @mbarrien makes a good case for this. |
@@ -268,7 +277,12 @@ def resource(self, service_name, region_name=None, api_version=None, | |||
# and service model, the resource version and resource JSON data. | |||
# We pass these to the factory and get back a class, which is | |||
# instantiated on top of the low-level client. | |||
config = Config(user_agent_extra='Resource') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if config is not None
|
Updated per comment. You're okay with the deepcopy being used here? |
@mbarrien I think that's fine. Thanks for the pull request. |
This pull request adds a config argument to the
boto3.resource()
/boto3.session.resource()
function. This allows passing in a custom config to programatically set a signature version, an s3 addressing style, or any other argument from the botocore client config.It was done this way over passing a client argument in (as suggested in #168) because it prevents the user from passing in a client of the wrong service type, as illustrated in this hypothetical set of calls.
(You could make it so that resource ignores the
service_name
argument passed into it ifclient
is specified, but that's really confusing sinceservice_name
is a required argument ofboto3.resource()
.)The only other non-straightforward thing in this pull request that would be nice to have feedback on is the
copy.deepcopy
performed if the config has not passed inuser_agent_extra
. This was done so that the incoming argument is not modified, but another possible semantic is that we useuser_agent_extra
untouched if a config is passed in, not attempting to override with a default value. Any preference, or okay as is?