readdir must return strings for FilePathsBase compatibility#230
readdir must return strings for FilePathsBase compatibility#230ExpandingMan wants to merge 10 commits intoJuliaCloud:masterfrom
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 |
ericphanson
left a comment
There was a problem hiding this comment.
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} = pathwhich 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. |
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
rmon directories is currently broken), so I'm hoping we can get this merged relatively quickly.