-
-
Notifications
You must be signed in to change notification settings - Fork 719
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
CI failure due to dependency conflict #8614
Comments
Yes, s3fs (and gcsfs) are hard pinned to exactly the same version as fsspec, and have been for a long time. They are always released within hours of each other. The latest release is 2024.3.1. I am thinking that the introduction of hatch in fsspec/filesystem_spec#1553 has caused the dev version to be called "2024.3.2.XXX" instead of "2024.3.1.XXX" as versioneer used to do. I am not sure how to change this convention. |
OK, I don't want our entire CI to be blocked by this and opened #8615 to temporarily just run CI against stable versions until this is figured out |
fsspec/filesystem_spec#1569 should fix this, if you care to try |
#8618 tries this |
Please try again with main/master whenever you think the caches might have cleared. |
did that on my revert pr |
All our CI jobs with python>3.10 are failing due to a dependency resolution conflict
cc @martindurant are you aware of anything that caused this hard pinning between s3fs and fsspec?
e.g. https://github.com/dask/distributed/actions/runs/8619396892/job/23704420478?pr=8610
The text was updated successfully, but these errors were encountered: