Tables v1.0.0 is restricting CSV.jl version

[ianfiske]

I experienced this and also was reported in https://discourse.julialang.org/t/csv-stuck-on-old-version/34581. We don't quite understand the version interaction here, but perhaps you can take a look? Installing Tables 1.0.0 is reverting CSV to the old 0.3.1.

[davidanthoff]

I believe the problem is that there are lots of old versions of various packages out there that have a dep on Tables.jl without proper version bounds. So these old versions of packages essentially declare "I am compatible with any version of Tables". So now you get those old versions over newer versions that properly declare that they are not compatible with Tables 1.0. The error here is really with what these downstream packages did in the past, not with Tables.

I think the only solution that will fix this properly is to modify the general registry and put proper bounds on the Tables dependency on all these old versions of all packages that depend on Tables.

[ianfiske]

Ah, that makes sense. Thanks @davidanthoff . Looks like JuliaData/CSV.jl#574 might also fix this. Will see!

[quinnj]

Yes, @davidanthoff is correct. There was at least one case of a past DataFrames release (0.19.4) that had bounds on Tables like ">= 0.2.3", so for packages upgrading, it will roll DataFrames back to that version because it seems to "support" Tables.jl 1.0. There have been a few cases of bumps in the road for the entire JuliaLang package ecosystem as things have transitioned from the old METADATA, the new Pkg.jl system, and as packages have started tagging 1.0 releases.

[ianfiske]

Thanks @quinnj . It does seem strange that Pkg chooses to downgrade many packages in order to update one package, even though the user does not explicitly want to upgrade Tables. Perhaps the package version constraint solver could be adjusted for this situation to match the user's expectation a bit closer.

[tpapp]

@ianfiske: if you don't want the suggestion about the resolver to get lost maybe mention this in an issue in the Pkg repository. What happened with CSV/Tables could provide a nice example, or a test case.

[davidanthoff]

I think what really should happen is that someone looks through the general registry and just fixes all deps that don't have an upper bound, I think every instance of that will sooner or later run into this problem. It really is a one-time exercise, but quite cumbersome...