Allow passing predefined_acl via gcs blob_properties#727
Allow passing predefined_acl via gcs blob_properties#727ddelange wants to merge 1 commit intopiskvorky:developfrom
Conversation
e2845d7 to
1467602
Compare
|
Is it possible to set the ACL after the upload is complete? If we can do this bypassing smart_open, that would be ideal. |
|
do you mean as a fallback for gcs <= 2.6? it was my first thought too. but since I dont use gcs, I had to do a deep dive into the code and have not found a way to set ACL after upload: there is so using |
|
I meant as a primary (only) approach. This looks relevant: https://cloud.google.com/storage/docs/xml-api/put-object-acls |
|
looks like this PR can be superceded by #729 (comment) |
|
OK, thank you. Closing in favor of #729 |
Title
Allow passing predefined_acl via gcs blob_properties
Motivation
Similar to #726, it should be possible to set an ACL for gcs uploads, as it is for s3.
It turns out you can't set an ACL to a gcs blob object directly ref stevearc/pypicloud#317.
Tests
If you're fixing a bug, consider test-driven development:
If you're implementing a new feature, include unit tests for it.
Make sure all existing unit tests pass.
You can run them locally using:
If there are any failures, please fix them before creating the PR (or mark it as WIP, see below).
Work in progress
If you're still working on your PR, include "WIP" in the title.
We'll skip reviewing it for the time being.
Once you're ready to review, remove the "WIP" from the title, and ping one of the maintainers (e.g. mpenkov).
Checklist
Before you create the PR, please make sure you have:
Workflow
Please avoid rebasing and force-pushing to the branch of the PR once a review is in progress.
Rebasing can make your commits look a bit cleaner, but it also makes life more difficult from the reviewer, because they are no longer able to distinguish between code that has already been reviewed, and unreviewed code.