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
feat(storage): mark preserve_acl as deprecated #9518
Conversation
new_blob.acl.save(acl={}, client=client) | ||
if preserve_acl is not None: | ||
warnings.warn( | ||
"The 'preserve_acl' argument is deprecated. Please update the bucket's ACL manually.", |
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.
This isn't "deprecation": we are changing the behavior, and emitting a warning. If we are going to deprecate the argument, then we should preserve the existing behavior, and emit an explicit deprecation, e.g.:
if preserve_acl is not None:
warnings.warn(
"The 'preserve_acl' argument is deprecated. For forward compatibility, "
"please update the blob's ACL manually.",
DeprecationWarning,
stacklevel=2,
)
if not preserve_acl and preserve_acl is not None:
new_blob.acl.save(acl={}, client=client)
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 we do that then, the warning will always be emitted. I think the change makes sense. Otherwise we can do a soft deprecation and only mark it in documentation.
storage/tests/unit/test_bucket.py
Outdated
SOURCE, BLOB_NAME, DEST, NEW_NAME | ||
source.copy_blob(blob, dest, NEW_NAME, client=client, preserve_acl=False) | ||
mock_warn.assert_called_once_with( | ||
"The 'preserve_acl' argument is deprecated. Please update the bucket's ACL manually.", |
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.
Please don't assert the warning message (it also happens to be incorrect, as the ACL is for the blob, not its bucket).
ISTM that we could make the |
@tseaver just closing the loop, as noted in the reference issue, let's not copy the ACL for the user. Instead it would be better for the user to supply blob metadata that can be used in the copy request. It's a clear opt-in. Let's deprecate this field and instead look at introducing acl= parameter a user can set in a subsequent PR? |
@frankyn Seems like we should provide a mechanism for copying any properties into the new blob. Maybe the most elegant would be to add a new method to source = source_bucket.blob('source-name')
dest = dest_bucket.blob('dest-name')
dest.content_type = source.content_type
# Copy other properties here?
dest.copy_from(source, copy_acl=True) |
This exact question came up in Ruby, short update: The GCS API will copy a subset of metadata from the object on copy or rewrite (excluding ACL's). I like the example: source = source_bucket.blob('source-name')
dest = dest_bucket.blob('dest-name')
dest.content_type = source.content_type
# User Modifies ACLs and copy_from only uses source for its media.
dest.copy_from(source)
# no additional parameters here "unless" the user wants to copy over existing metadata in the same way GCS does. We did this in Ruby using a flag force_metadata_copy to respect GCS behavior when a resource is provided. Otherwise, only the metadata provided on the copy/rewrite will be kept. |
@frankyn So, the question is that we need probably separate those tasks. First, deprecate |
Please reopen in the new repo, if this PR is still on track, thanks! |
Closes: #9482
As was asked in the comments, argument
preserve_acl
marked as deprecated.