Plots downgraded GR to 0.52 for no good reason

General Usage
, ,
1

I’m a person who does ] up all the time, today I found the Plots.jl is downgrading GR.jl back to 0.52 for no reason.
If I go to ] dev Plots, and remove older versions of GR in [compat], keeps only the latest 0.57, and ] up can successfully install GR 0.57.5, the latest version.
From this experiment, there is no conflict or compact request to make it use GR 0.52, so why it’s using an old 0.52 version rather than latest 0.57?

1 Like
2

Try

pkg> add Plots@whatever-the-latest-version-is

and the error message will tell you what’s holding it back.

3

Plots.jl is the latest version, but GR is not, which is required by Plots.jl.
I tried add Plots@1.15.2 on a new empty environment, the GR is still 0.52, no any error message.

4

It seems that although GR 0.57 and 0.52 are all compatible, but 0.52 is preferred than 0.57.
So if you just add Plots like normal, the old 0.52 of GR get installed

5

So what happens when you try to add the latest GR?

6

Also I tried to add GR@0.57.5, it also has no error at all.

    Updating `C:\Users\zhang\Project\CorticalSpikingNetwork.jl\Project.toml`
  [28b8d3ca] ↑ GR v0.52.0 ⇒ v0.57.5
    Updating `C:\Users\zhang\Project\CorticalSpikingNetwork.jl\Manifest.toml`
  [c87230d0] ↑ FFMPEG v0.3.0 ⇒ v0.4.0
  [28b8d3ca] ↑ GR v0.52.0 ⇒ v0.57.5
  [cd3eb016] ↑ HTTP v0.8.19 ⇒ v0.9.9
  [5c2747f8] + URIs v1.3.0
  [6e34b625] ↓ Bzip2_jll v1.0.8+0 ⇒ v1.0.6+5
  [83423d85] ↓ Cairo_jll v1.16.1+0 ⇒ v1.16.0+6
  [b22a6f82] ↓ FFMPEG_jll v4.4.0+0 ⇒ v4.3.1+4
  [a3f928ae] ↓ Fontconfig_jll v2.13.93+0 ⇒ v2.13.1+14
  [d7e528f0] ↓ FreeType2_jll v2.10.4+0 ⇒ v2.10.1+5
  [0656b61e] + GLFW_jll v3.3.4+0
  [d2c73de3] + GR_jll v0.57.3+0
  [3b182d85] - Graphite2_jll v1.3.14+0
  [2e76f6c2] - HarfBuzz_jll v2.8.1+0
  [aacddb02] + JpegTurbo_jll v2.1.0+0
  [dd192d2f] + LibVPX_jll v1.10.0+0
  [7e76a0d4] + Libglvnd_jll v1.3.0+3
  [89763e89] + Libtiff_jll v4.3.0+0
  [ea2cea3b] + Qt5Base_jll v5.15.2+0
  [a2964d1f] + Wayland_jll v1.17.0+4
  [2381bf8a] + Wayland_protocols_jll v1.18.0+4
  [935fb764] + Xorg_libXcursor_jll v1.2.0+4
  [d091e8ba] + Xorg_libXfixes_jll v5.0.3+4
  [a51aa0fd] + Xorg_libXi_jll v1.7.10+4
  [d1454406] + Xorg_libXinerama_jll v1.1.4+4
  [ec84b674] + Xorg_libXrandr_jll v1.5.2+4
  [cc61e674] + Xorg_libxkbfile_jll v1.1.0+4
  [12413925] + Xorg_xcb_util_image_jll v0.4.0+1
  [2def613f] + Xorg_xcb_util_jll v0.4.0+1
  [975044d2] + Xorg_xcb_util_keysyms_jll v0.4.0+1
  [0d47668e] + Xorg_xcb_util_renderutil_jll v0.3.9+1
  [c22f9ab0] + Xorg_xcb_util_wm_jll v0.4.1+1
  [35661453] + Xorg_xkbcomp_jll v1.4.2+4
  [33bec58e] + Xorg_xkeyboard_config_jll v2.27.0+4
  [0ac62f75] ↓ libass_jll v0.15.1+0 ⇒ v0.14.0+4
  [f638f0a6] ↓ libfdk_aac_jll v2.0.2+0 ⇒ v0.1.6+4
  [1270edf5] ↓ x264_jll v2021.5.5+0 ⇒ v2020.7.14+2
  [dfaa095f] ↓ x265_jll v3.5.0+0 ⇒ v3.0.0+3
  [d8fb68d0] + xkbcommon_jll v0.9.1+5
7

So is Pkg decide the priority by how many packages get updated and how many get downgraded?
Because from 0.52 → 0.57, there are only 4 get updated, but 9 get downgraded, so 0.52 is preferred?

Maybe Pkg should consider the priority by level of dependency rather than total number.
Since the packages get downgraded are not direct dependencies of Plots.jl, but the upgraded ones are indeed direct dependency. Keep the direct dependency more updated is more reasonable isn’t it?

8

There are various options for the resolver, see

https://pkgdocs.julialang.org/dev/api/#Pkg.add

9

If there are multiple “pareto optimal” solutions you will just get one of them. If you need specific version of packages you ensure that by using the compat section in the project file. For example, if you need 0.57 you can add:

[compact]
GR = "0.57"

to your project file of the current project.

2 Likes
10

I’m suggesting that having direct dependency fall behind by a large number is much worse than having indirect dependency fall behind by a bit.
The choice of using GR@0.52 should not be a “pareto optimal” solution in this scenario.

Btw the choice is not like this few days before, since GR@0.52 is not usable due to a bug that makes the plotting very very small in Pluto, it would be obvious to find it. I checked the Project.toml of Plots and GR, didn’t find anything that could cause this. So it’s some even more basic dependency that causes the change of choice.

Imagine a new user of julia come and use the Plots in Pluto, and find that the plotting extremely small, and with a lot searching, and find out it was a long fixed bug, but for some reason it’s not the latest version by default, and there is no incompatible issue at all, and he should add an explicit compat entry in the toml and carefully maintaining that config in the future.

Plots should remove some older version in [compact], and Pkg maybe should optimize the strategy to choose a optimal solution more wisely.

Also from Packages downgraded after `Pkg.update()`? · Issue #2550 · JuliaLang/Pkg.jl · GitHub I found there is a log of how Pkg decide which version to choose when there is no choice left, can I print that when there is multiple choices?

11

Yes, that situation is not ideal. The suggestion for compat was more a way to directly deal with the current situation, not a way to say that the situation is perfect as is.

This is a good suggestion, it’s mostly a question of someone willing to do the work.

4 Likes