-
Notifications
You must be signed in to change notification settings - Fork 34
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
Use list_objects_v2 to check isdir #265
Conversation
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Since this is just changing the behaviour for root bucket paths I think it's fine. You should add tests for each of the conditions though:
|
I think these changes are fine, but don't really solve the root problem here, which is to add the permissions needed to the role? We're now requiring users to have permissions to However, I do think those are the more correct permissions to require. I would also tag this as a |
You already need |
Oh rad, I missed that! Just needs test cases and it should be good to go! Side thought, made we should include in our documentation the permissions users would need to run these functions? |
test/s3path.jl
Outdated
@test isdir(path) == true | ||
|
||
# No Such Bucket | ||
path = S3Path("s3://some_non_existent_bucket_7051649213"; config=config) |
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.
We should make this an actual AWSException w/ the NoSuchBucket
error so we're not dependent on someone not making this an actual bucket.
bors try |
tryBuild succeeded: |
test/s3path.jl
Outdated
code, | ||
"", | ||
nothing, | ||
AWS.HTTP.Exceptions.StatusError(404, "", "", ""), | ||
nothing, |
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.
[JuliaFormatter] reported by reviewdog 🐶
code, | |
"", | |
nothing, | |
AWS.HTTP.Exceptions.StatusError(404, "", "", ""), | |
nothing, | |
code, "", nothing, AWS.HTTP.Exceptions.StatusError(404, "", "", ""), nothing |
test/s3path.jl
Outdated
patch = @patch AWSS3.S3.list_objects_v2( | ||
args...; kwargs... | ||
) = throw(test_exception) |
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.
[JuliaFormatter] reported by reviewdog 🐶
patch = @patch AWSS3.S3.list_objects_v2( | |
args...; kwargs... | |
) = throw(test_exception) | |
patch = @patch function AWSS3.S3.list_objects_v2(args...; kwargs...) | |
throw(test_exception) | |
end |
test/s3path.jl
Outdated
patch = @patch AWSS3.S3.list_objects_v2( | ||
args...; kwargs... | ||
) = throw(test_exception) |
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.
[JuliaFormatter] reported by reviewdog 🐶
patch = @patch AWSS3.S3.list_objects_v2( | |
args...; kwargs... | |
) = throw(test_exception) | |
patch = @patch function AWSS3.S3.list_objects_v2(args...; kwargs...) | |
throw(test_exception) | |
end |
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.
Seems fine to me. I do think we should bump the minor release though.
Project.toml
Outdated
@@ -1,6 +1,6 @@ | |||
name = "AWSS3" | |||
uuid = "1c724243-ef5b-51ab-93f4-b0a88ac62a95" | |||
version = "0.9.8" | |||
version = "0.9.9" |
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.
Technically we're changing behaviour that folks could depend on?
version = "0.9.9" | |
version = "0.10.0" |
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.
I'm somewhat unsure if that's the case, what behaviour could someone depend on? Theoretically you already need list_objects
permissions to do an isdir
on a non root bucket. I guess this could potentially be an issue for someone that is only doing an isdir
on a root bucket somehow? I'm fine to bump the minor if you still think that should be the case
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.
Bumped the version regardless
bors r+ |
265: Use list_objects_v2 to check isdir r=fchorney a=fchorney isdir for an s3 directory currently calls `s3_list_buckets` to check if a top level bucket is a directory. I ran into an issue where the role I was using didn't have permissions to call `list_buckets`. This change essentially calls `S3.list_objects_v2` with `max-keys` set to `0` as we don't actually need to retrieve any keys. If the bucket exists and you have permissions for it, it will return with no error, but if the bucket doesn't exist we return false or raise an exception if some other error occurred. Not too sure if this is exactly how we want to go about this (re: the exceptions), so if you have any suggestions let me know. I don't think there should be any issues for using `S3.list_objects_v2` instead of `s3_list_buckets`. Co-authored-by: Fernando Chorney <[email protected]> Co-authored-by: Fernando Chorney <[email protected]>
Build failed: |
This is frustrating. |
I would have to not only push the change to |
Also, FYI, I am getting my own CI/CD failures on Minio.jl right now and I have no clue why. I have successful tests locally with multiple different binaries so I don't know what's going on. I'm going to try updating the package to use |
This needs to get in ASAP for something I am working on, so I think it makes sense that this will definitely be the 0.10.0 release. |
Tagging this as a This would punt the need for this awkward version bump except in the case of a Any thoughts? @fchorney @rofinn @ExpandingMan |
sure I'm fine with going to 1.0.0 |
Yeah, I think the core behaviour hasn't changed much in the last couple years and I don't think we have a roadmap for major breaking changes. If we ever get around to doing the FilePathsBase redesign we've been discussing for a while that can just be a 2.0 release. https://gitlab.com/ExpandingMan/FilePaths2.jl
I don't think the awkward dependency situation should guide our decision on tagging a 1.0 release though. We should probably plan to resolve the package interdependencies regardless of which release we do. We should either merge minio into a module in AWSS3 or limit AWSS3 to a test dependency for minio? |
So in that case, we'd need |
Minio.jlI have just tagged Minio.jl 0.2.0 which nominally includes support for AWSS3.jl. Unfortunately it seems that the minio devs are on a warpath against single-node use cases which drastically limits its usefulness for unit testing. Besides what was mentioned in that thread, I have also noticed that minio is now rather idiosyncratic about what directory it wants to mount, even when empty; when trying to rewrite the unit tests I notice that it freaks out if you give it absolute paths like Sadly at this point I would not be totally surprised if minio ultimately became totally useless for us here, but there are not many alternatives. On the other hand, they have hit 1.0 so it'll likely be a while before they make further breaking changes. tagging of AWSS3.jlI strongly recommend we wait on tagging a 1.0 of this. In my opinion this package still has major issues that are unresolved, in particular we still lack a file path abstraction which is appropriate for all use cases. Some of my previous comments on that can be found here. In my opinion we still very much need a new or completely overhauled file paths package at which point the many "gotchas" in the weirdly idiosyncratic AWSS3.jl code can be eliminated. By the way, I have not been working on FilePaths2.jl (either there or as an overhaul of FilePathsBase.jl). I'm satisfied I have figured out what is basically the "correct" approach, however there are still many engineering subtleties to be resolved, in particular syncing (i.e. between remote file systems and local path object). If there is a broad consensus that we really do need to get this done I might consider picking it up again, I was rather hesitant to put in a ton of effort just to wind up splitting the ecosystem in 2 or 3 pieces. |
bors try |
tryBuild succeeded: |
since I need this to go in, is everyone fine with just keeping this 0.10 and we can do a 1.0 release later? |
bors r+ |
isdir for an s3 directory currently calls
s3_list_buckets
to check if a top level bucket is a directory. I ran into an issue where the role I was using didn't have permissions to calllist_buckets
.This change essentially calls
S3.list_objects_v2
withmax-keys
set to0
as we don't actually need to retrieve any keys. If the bucket exists and you have permissions for it, it will return with no error, but if the bucket doesn't exist we return false or raise an exception if some other error occurred.Not too sure if this is exactly how we want to go about this (re: the exceptions), so if you have any suggestions let me know. I don't think there should be any issues for using
S3.list_objects_v2
instead ofs3_list_buckets
.