-
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
add join
keyword to readdir
#129
Conversation
bors try |
tryBuild failed: |
Any particular errors which popped up? I assume that it's probably a credential thing. At the very least you need credentials in ENV VARs /
I think keeping this behind a |
Ah, this would be it, I'm on a restricted role. I could set something up but for this PR hopefully CI will be enough. Would you mind re-running bors? I think I fixed the issues in my last two commits. |
bors try |
tryBuild failed: |
sorry, looks like I had a copy-paste error there, try again? |
bors try |
Bump / Is anything I need to do here? 🙂 |
@rofinn has more strong opinions on |
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. Just a couple minor suggestions, I've also made an issue to add this to FilePathsBase.jl as well.
@mattBrzezinski Do we need to manually trigger bors or something? |
Yes they work w/
|
thanks for the review! I've made those changes. |
bors r+ |
sort && sort!(results) | ||
|
||
# Return results, possibly joined with the root path if join=true | ||
return join ? joinpath.(fp, results) : results |
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.
Hmm, one thing I just realized about this is that it introduces a type instability cause join
determines whether we return strings or paths.
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.
Yeah, it does-- I've been using this and for me having the functionality has been well worth it, but it might depend on your use-case. Generally either I am using it in the REPL (in which case it doesn't matter), or in code that generally ends up like
for file in readdir(path; join=true)
# some kind of filtering...
endswith(string(file), ".arrow") || continue
process_file!(results, file)
end
and the function-barrier (process_file!
) means the instability is not an issue.
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 trying to remember, is there a reason you didn't want to use readpath
? I'm wondering if for now I should just add those flags to both readpath
and readdir
, but just make the only difference that one return paths and one returns strings? In the future, I may make a breaking release which unifies the API and always returns paths for readdir
.
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.
Ah, is that what readpath
does? I didn't know that function exists and it's not really documented what it does:
julia> using FilePathsBase
help?> readpath
search: readpath
readpath(fp::P) where {P <: AbstractPath} -> Vector{P}
Usually I stick to the Base API since I might have a mix of S3Paths and Base (string) paths.
(To be clear, join
doesn't just return S3Path's vs strings, but rather it determines or not it's the full path, including the bucket etc, or just the filename).
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.
(To be clear, join doesn't just return S3Path's vs strings, but rather it determines or not it's the full path, including the bucket etc, or just the filename).
Yeah, I was just wondering if it would have made more sense to do joinpath.(string(fp), results)
in the readdir
function and left returning paths to readpath
?
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'd rather accept the type instability than to try to explain to users (and remember myself) why it gives back a full path but you can't actually use it to read bytes etc
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.
Okay. I've opted away from the type instability in FilePathsBase since I have less control over how it'll be used. It also means I can support that keyword without introducing a breaking change. I may change readdir
to always return a path type if a path type is given in the future... in which case I'll plan to update S3Path
as well.
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 may change readdir to always return a path type if a path type is given
is there a way to do that while matching Base’s semantics? Like a RelativePath type or something?
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've looked into the RelativePath
idea, and it's very verbose. Without a proper traits based approach I don't think that's gonna happen anytime soon. Mostly likely I'd just wrap the resulting string in an appropriate path type and expect subtypes to decide what they want to do. I think there's also an issue where folks want basename
to return a path as well. Obviously that change would be very breaking and I'm not clear on the tradeoffs yet, so it probably won't happen right away.
This keyword was added to Base in JuliaLang/julia#33113, which made it into Julia 1.4.
I couldn't run the tests locally, but I tested with an example and it seemed to work. The new tests in
verify_files(path::AbstractPath)
need the Base method, so will fail on Julia 1 - 1.3. Should I put them behind aVERSION
check, or just drop them?