-
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
readdir must return strings for FilePathsBase compatibility #230
base: master
Are you sure you want to change the base?
Conversation
This is a little worrying because we are also testing against what is apparently the wrong behavior... I don't think FilePathsBase has changed, but I'm not entirely sure. bors try |
Yep, FilePathsBase made a patch release that added We can make this change here*, but it would definitely need to be a breaking change for AWSS3.jl. *: I think these are the wrong semantics, because it means |
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.
Needs breaking version bump if we are going to do this
In my opinion breaking with FilePathsBase would drastically diminish the usefulness of this package. The current state of the package is rather broken, so this needs to be done until and unless you won't to re-implement everything. bors try |
tryAlready running a review |
I'm not sure what's happening with bors. I thought it got stalled out because I made another commit, but now it says it's already running and doesn't want to run. |
I think Bors might be broken; last time I tried it in #229 it timed out. Not sure what's going on though, maybe @mattBrzezinski can look into it?
Well, we could just restrict compat to non-broken FilePathsBase? This PR could do that instead. Ref #226 (comment) Or we could just add the workaround Base.parse(::Type{P}, path::P; kwargs...) where {P<:S3Path} = path which is probably the nicest fix for now-- shouldn't break any existing code, and will stop the errors from #227 |
Restricting the FilePathsBase versoin without fixing this seems like a bad idea, because then this package will just get stuck on an effectively unmaintained version of it. If AWSS3 drops FilePathsBase, then so be it, but before that has happened it doesn't make sense to restrict it. I also don't think adding a method to So yes, even though I disagree that it is desirable, there is a case to be made for dropping FilePathsBase, but in the meantime, it seems better to try to keep things working properly. |
Ok, but breaking the fact that you can |
I'm re-thinking my stance against extending Btw, please let me know what you think about my draft PR to FilePathsBase in that thread. |
tryTimed out. |
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.
Test formatting changes
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Co-authored-by: Curtis Vogt <curtis.vogt@gmail.com>
Sorry, was busy. Let's try running again bors try |
tryBuild succeeded: |
Currently doing
readdir(p, join=true)
returns an array of paths. This is a problem because FilePathsBase expects it to be strings in all cases.This is breaking things pretty badly (e.g. even
rm
on directories is currently broken), so I'm hoping we can get this merged relatively quickly.