In some cases, Pkg downgrades many packages to update one implicit dependency

[ianfiske]

I have an environment that only depends on Tables.jl implicitly. When I did ] up, Tables updated and many direct dependencies of my environment downgraded to very old versions. It seems like Pkg should prioritize not downgrading any explicit dependencies, especially just to satisfy updating some implicit dependency.

Mostly noting this here as suggested by @tpapp in JuliaData/Tables.jl#152 so that this issue doesn't get lost. Also see https://discourse.julialang.org/t/csv-stuck-on-old-version/34581. I apologize, but this one is a bit difficult for me to create a minimum repro example, especially since the state of the General registry is changing as packages are being registered.

In the links above, @davidanthoff mentions that the solution is to add upper bounds to old versions of packages in the registry so that they cannot be viewed as fallback compatibility. I still feel like there is a version-resolver issue to be fixed.

[KristofferC]

In the links above, @davidanthoff mentions that the solution is to add upper bounds to old versions of packages in the registry so that they cannot be viewed as fallback compatibility.

Yes, I want to run https://github.com/bcbi/RetroCap.jl on the Registry. I am just a bit scared of breaking a bunch of things.

In general, we take the view that if there are many different pareto optimal you will just get one of them and if you need specific versions you should specify that in the compat section. Someone could of course work on the resolver to determine which of these points would be "best" to take according to some heuristic but performance shouldn't suffer too much.

[ianfiske]

Yes, I want to run https://github.com/bcbi/RetroCap.jl on the Registry. I am just a bit scared of breaking a bunch of things.

That looks like a great idea. To relieve your fear of breakage, would it be possible to set-up another registry for testing, say "GeneralCapped", where it tracks General but applies RetroCap? Then any brave testing users can use GeneralCapped instead of General and report any issues? I would volunteer to test it. I understand it's a nontrivial effort to set up GeneralCapped.

In general, we take the view that if there are many different pareto optimal you will just get one of them and if you need specific versions you should specify that in the compat section. Someone could of course work on the resolver to determine which of these points would be "best" to take according to some heuristic but performance shouldn't suffer too much.

Thanks for the explanation. I looked at the source in Resolver and concluded this would be too big an effort for me at the moment. The current philosophy works well enough.

[KristofferC]

The "retro cap" has been done so this should be slightly less problematic.