# Plots/GR broken after updating Pluto dependencies

**URL:** <https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546>\
**Category:** General Usage\
**Tags:** plots, gr\
**Created:** [June 19, 2023, 8:26am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546 "2023-06-19T08:26:17Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![schlichtanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/schlichtanders/32/32145_2.png) [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)\
**Post date:** [June 19, 2023, 8:26am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/1 "2023-06-19T08:26:17Z")

</div>

I am running Pluto and just installed the most recent Plots.jl which unfortunately failed. I think this should never happen, maybe some missing tests on GR or Plots.jl for interacting with previously installed versions?

How can I fix it?

```julia
begin
	import Pkg
	Pkg.build("GR")
end

```

```julia
Error building `GR`:

tar (child): downloads/gr-0.49.0-Linux-aarch64.tar.gz: Cannot open: No such file or directory

```

---

<div class="post-metadata">

**Author:** ![schlichtanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/schlichtanders/32/32145_2.png) [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)\
**Post date:** [June 19, 2023, 8:42am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/2 "2023-06-19T08:42:50Z")

</div>

uninstalling and reinstalling seemed to have helped…  
UPDATE: I also deleted the artifact folder following [this other discourse thread](https://discourse.julialang.org/t/gr-doesnt-work-in-julia/88022/10). Probably this was what actually helped

It would be great if such bug could be prevented by a respective test. Probably hard to reproduce… Is this a typical Julia problem?  
I mean to have bugs here and there, even with stable packages, which just never will make into some automated tests because the interactions are too huge? What can we do about it?

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [June 19, 2023, 9:19am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/3 "2023-06-19T09:19:54Z")

</div>

Most recent version of GR is 0.72, but you were trying to install 0.49, which is over 3-year old.

---

<div class="post-metadata">

**Author:** ![schlichtanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/schlichtanders/32/32145_2.png) [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)\
**Post date:** [June 19, 2023, 9:34am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/4 "2023-06-19T09:34:43Z")

</div>

Thank you for pointing out. That is almost funny.

User perspective: Installing most recent Plots package  
What you get: 3 years old GR version

😄 something is wrong with the installation process. A bug in Pkg? Let’s hope for some more reproducible examples.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [June 19, 2023, 9:36am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/5 "2023-06-19T09:36:04Z")

</div>

More likely crowded environment?

---

<div class="post-metadata">

**Author:** ![schlichtanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/schlichtanders/32/32145_2.png) [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)\
**Post date:** [June 19, 2023, 9:38am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/6 "2023-06-19T09:38:38Z")

</div>

It is crowded in the sense that I am running several Pluto notebooks with different dependencies (Pluto managed).

But it is not crowded in any reasonable sense. Normal use of Julia + Pluto. A normal user would expect everything to just work. Even I expected everything to just work (and luckily, for now, it does again).

---

<div class="post-metadata">

**Author:** ![schlichtanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/schlichtanders/32/32145_2.png) [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)\
**Post date:** [June 19, 2023, 9:39am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/7 "2023-06-19T09:39:42Z")

</div>

It seems this could be the right direction of solving it:

> <https://github.com/JuliaPlots/Plots.jl/issues/2877#issuecomment-1596777482>
>
> \## Details
> 
> I'm trying to get Plots up and running on the Nvidia Jetson to plo…t some GPU vs CPU benchmarks. I tried asking around on the \[discourse\](https://discourse.julialang.org/t/plots-build-precompilation-error-on-linux-aarch64/43334), however the post doesn't seem to get any traction. The crux of the issue is what happens after \`add Plots\`:
> 
> \`\`\` julia
> (@v1.4) pkg\> add Plots
> Resolving package versions...
> Installed ColorTypes ── v0.10.7
> Installed RecipesBase ─ v1.0.2
> Installed HTTP ──────── v0.8.17
> Installed Plots ─────── v1.5.6
> Updating \`~/.julia/environments/v1.4/Project.toml\`
> \[91a5bcdd\] + Plots v1.5.6
> Updating \`~/.julia/environments/v1.4/Manifest.toml\`
> \[6e34b625\] + Bzip2\_jll v1.0.6+2
> .
> .
> .
> \[8bb1440f\] + DelimitedFiles
> Building Plots → \`~/.julia/packages/Plots/XbAWb/deps/build.log\`
> 
> (@v1.4) pkg\> build Plots
> Building GR ───→ \`~/.julia/packages/GR/8mv9N/deps/build.log\`
> ┌ Error: Error building \`GR\`:
> │ tar (child): downloads/gr-0.51.0-Linux-aarch64.tar.gz: Cannot open: No such file or directory
> │ tar (child): Error is not recoverable: exiting now
> │ tar: Child returned status 2
> │ tar: Error is not recoverable: exiting now
> │ \[ Info: Downloading pre-compiled GR 0.51.0 Linux binary
> │ ┌ Error: Download failed: curl: (22) The requested URL returned error: 404 Not Found
> │ └ @ Base download.jl:43
> │ ┌ Error: Download failed: curl: (22) The requested URL returned error: 404
> │ └ @ Base download.jl:43
> │ \[ Info: Using insecure connection
> │ ┌ Error: Download failed: curl: (22) The requested URL returned error: 404 Not Found
> │ └ @ Base download.jl:43
> │ \[ Info: Cannot download GR run-time
> │ ERROR: LoadError: failed process: Process(\`tar xzf downloads/gr-0.51.0-Linux-aarch64.tar.gz\`, ProcessExited(2)) \[2\]
> │
> │ Stacktrace:
> │ \[1\] pipeline\_error at ./process.jl:525 \[inlined\]
> │ \[2\] run(::Cmd; wait::Bool) at ./process.jl:440
> │ \[3\] run(::Cmd) at ./process.jl:438
> │ \[4\] top-level scope at /home/coz/.julia/packages/GR/8mv9N/deps/build.jl:134
> │ \[5\] include(::String) at ./client.jl:439
> │ \[6\] top-level scope at none:5
> │ in expression starting at /home/coz/.julia/packages/GR/8mv9N/deps/build.jl:74
> └ @ Pkg.Operations /buildworker/worker/package\_linuxaarch64/build/usr/share/julia/stdlib/v1.4/Pkg/src/Operations.jl:892
> Building Plots → \`~/.julia/packages/Plots/VA7Vx/deps/build.log\`
> 
> julia\> using Plots
> \[Info: Precompiling Plots \[91a5bcdd-55d7-5caf-9e0b-520d859cae80\]
> Cannot open cache file "/home/coz/.julia/compiled/v1.4/NaNMath/k9Y1O\_Vt7ED.ji.N4T5qf" for writing.
> ERROR: LoadError: Failed to precompile NaNMath \[77ba4419-2d1f-58cd-9bb1-8ffee604a2e3\] to /home/coz/.julia/compiled/v1.4/NaNMath/k9Y1O\_Vt7ED.ji.
> Stacktrace:
> \[1\] error(::String) at ./error.jl:33
> \[2\] compilecache(::Base.PkgId, ::String) at ./loading.jl:1272
> \[3\] \_require(::Base.PkgId) at ./loading.jl:1029
> \[4\] require(::Base.PkgId) at ./loading.jl:927
> \[5\] require(::Module, ::Symbol) at ./loading.jl:922
> \[6\] include(::Module, ::String) at ./Base.jl:377
> \[7\] top-level scope at none:2
> \[8\] eval at ./boot.jl:331 \[inlined\]
> \[9\] eval(::Expr) at ./client.jl:449
> \[10\] top-level scope at ./none:3
> in expression starting at /home/coz/.julia/packages/Plots/XbAWb/src/Plots.jl:135
> ERROR: Failed to precompile Plots \[91a5bcdd-55d7-5caf-9e0b-520d859cae80\] to /home/coz/.julia/compiled/v1.4/Plots/ld3vC\_Vt7ED.ji.
> Stacktrace:
> \[1\] error(::String) at ./error.jl:33
> \[2\] compilecache(::Base.PkgId, ::String) at ./loading.jl:1272
> \[3\] \_require(::Base.PkgId) at ./loading.jl:1029
> \[4\] require(::Base.PkgId) at ./loading.jl:927
> \[5\] require(::Module, ::Symbol) at ./loading.jl:922
> \`\`\`
> Some failed attempts to fix this:
> \`\`\` bash
> rm -r .julia/compiled/v1.4/NaNMath
> sudo chmod 777 .julia/compiled/v1.4/NaNMath
> \`\`\`
> 
> \### Backends
> 
> This bug occurs on ( insert \`x\` below )
> 
> Backend | yes | no | untested
> \-------------|-----|-----|---------
> gr (default) | x | |
> pyplot | | | x
> plotly | | | x
> plotlyjs | | | x
> pgfplotsx | | | x
> inspectdr | | | x
> 
> \### Versions
> 
> Plots.jl version: v1.5.6
> Backend version (\`\]st -m\`):
> \`\`\`
> (@v1.4) pkg\> st -m
> Status \`~/.julia/environments/v1.4/Manifest.toml\`
> ...
> \[28b8d3ca\] GR v0.51.0
> ...
> \[77ba4419\] NaNMath v0.3.4
> ...
> \`\`\`
> Output of \`versioninfo()\`:
> \`\`\`julia
> Julia Version 1.4.2
> Commit 44fa15b150\* (2020-05-23 18:35 UTC)
> Platform Info:
> OS: Linux (aarch64-unknown-linux-gnu)
> CPU: unknown
> WORD\_SIZE: 64
> LIBM: libopenlibm
> LLVM: libLLVM-8.0.1 (ORCJIT, generic)
> Environment:
> JULIA\_NUM\_THREADS = 4
> \`\`\`

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [June 19, 2023, 9:44am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/8 "2023-06-19T09:44:47Z")

</div>

Solve what? You commented on a ~~2-year~~ 3-year old issue. And as far as I could tell the problem was trying to use a GR own build of the library (probably aarch64 wasn’t supported back then?), _ **not** _ using the Artifacts system.

---

<div class="post-metadata">

**Author:** ![schlichtanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/schlichtanders/32/32145_2.png) [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)\
**Post date:** [June 19, 2023, 10:09am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/9 "2023-06-19T10:09:27Z")

</div>

Okay, please lets get this finished in a friendly manner:

- I added a remark to an issue because I rent into a weird error which got an exact hit on exactly this issue. The issue was rather long and I didn’t take the time to read through it, just hoping that someone could help. This actually became true. Sorry for hooking onto an old issue, but as you see it has true benefits. Here can be the question whether it is also beneficial for others… good question … and I can indeed imagine someone arguing that yes, if you hit this issue because you searched for a new bug which is significantly similar in error response, then others may also find this new link easier, even if it does not connect well to the old issue.

- the comment I linked to above is the following

> Ideally the checksum for the artifact is checked after download and if it doesn’t match the file is deleted and either a retry happens or you’d get a helpful error, but that would need to be handled by Pkg (don’t know what the current behaviour is).

- and for me it sounds very reasonable. So if someone would have a reproducible example of this error, it would make sense to open an issue with Pkg itself. Unfortunately my example is not reproducible, hence I fear uncomforting other people by just opening an issue which is not really solvable at all.

I feel slightly offended by your last response, hence I probably won’t answer further here, as the issue is resolved for me practically (my excuses for the inconveniences, there are other people which surelyare less sensible than I am).

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [June 19, 2023, 10:28am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/10 "2023-06-19T10:28:52Z")

</div>

> [@schlichtanders](#):
>
> I added a remark to an issue because I rent into a weird error which got an exact hit on exactly this issue. The issue was rather long and I didn’t take the time to read through it, just hoping that someone could help. This actually became true. Sorry for hooking onto an old issue, but as you see it has true benefits. Here can be the question whether it is also beneficial for others… good question … and I can indeed imagine someone arguing that yes, if you hit this issue because you searched for a new bug which is significantly similar in error response, then others may also find this new link easier, even if it does not connect well to the old issue.

What I’m saying is that most of the problems you faced are related to the fact that you’re somehow using an old version of GR, which apparently didn’t support Linux aarch64 back then? @BeastyBlacksmith’s comment overlooked the fact that you were _not_ using artifacts, but GR was trying to use own builds, so the comment “but that would need to be handled by Pkg” doesn’t apply at all here. So commenting on an old issue only created more confusion than necessary.

I’m sorry if you got offended by previous messages, but I’m trying to explain that you’re facing problems with trying to use an _ **old** _ version of GR. To get more actionable help it’d be better to report problems, if any, with more recent versions, it’s hard to retroactively fix 3-year old software. Today the build systems of `GR.jl` and `Plots.jl` are very different compared to back then.

---

<div class="post-metadata">

**Author:** ![schlichtanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/schlichtanders/32/32145_2.png) [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)\
**Post date:** [June 19, 2023, 11:49am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/11 "2023-06-19T11:49:51Z")

</div>

thank you very much. feels much better now.

I cannot assess whether or how what you are saying applies to my case. I have installed Plots by running `using Plots` in Pluto, which made this issue pop up. Sure there might be someway how I could get to a 3-year old software, but definitely it is nothing done by myself. The docker process which I am running on is about 1 week old (maximum, actually rather created today), and I have no caching so far for the docker, so that Julia libraries are definitely compiled when running first. Also no sysimage is used. It is plain Julia 1.9.

On the other hand following the tutorial with deleting the GR artifacts folder indeed worked. Sure, it might be some other interaction which is truly happening, but from a user perspective, that hint indeed solved my problem for now. So from my side it indeed still makes sense, that it could be some Pkg interaction which caused the problem.

Can also be GR problem, can also be Plots problem, can also be Pluto problem, but definitely it is not a Problem with a User who installed a 3-year old software. I guess this is the point where we got apart.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [June 19, 2023, 11:55am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/12 "2023-06-19T11:55:15Z")

</div>

The core of the issue remains - as you rightly pointed out upfrong - the lack of a reproducer. I agree that somehow getting a 3-year old GR version in a Pluto notebook warrants investigation, but I also agree with Mose that the most likely reason for something like this is an issue with the environment. If there’s no way to re-create the situation in which Pkg tries to install that 3-year old version I guess this one will have to go on the `¯\_(ツ)_/¯ one of these things` pile.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [June 19, 2023, 11:58am UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/13 "2023-06-19T11:58:34Z")

</div>

> [@schlichtanders](#):
>
> Can also be GR problem, can also be Plots problem, can also be Pluto problem, but definitely it is not a Problem with a User who installed a 3-year old software. I guess this is the point where we got apart.

There are two problems:

1. 3 years ago GR seemingly didn’t support aarch64 linux. I think this is _now_ fixed, but can’t retroactively fix old versions, this point isn’t actionable
2. you’re somehow getting a 3-year old version of GR. This is the main problem that should be avoided. I don’t know how you’re getting there, an empty environment wouldn’t cause that.

---

<div class="post-metadata">

**Author:** ![dlakelan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlakelan/32/8491_2.png) [@dlakelan](https://discourse.julialang.org/u/dlakelan)\
**Post date:** [June 19, 2023, 12:49pm UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/14 "2023-06-19T12:49:49Z")

</div>

> [@schlichtanders](#):
>
> But it is not crowded in any reasonable sense.

Are you running in an environment specifically made for these notebooks? Or are you running in the top level environment? My guess is it’s the top level environment and that you have hundreds of things installed there. I guess this because that’s exactly what I did when I started learning Julia in 2019.

I now have like 4 things in my top level environment and everything is run in local environments specific to those projects. It solves problems like yours and is the primary way to use Julia.

If you are doing that, then we have to look into why your local project environment is crowded enough that Pkg tries to pull 3yo versions. Usually that’d mean you have some complicated dependencies issue.

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [June 19, 2023, 12:58pm UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/15 "2023-06-19T12:58:52Z")

</div>

Doesn’t Pluto notebooks are completely self-contained?

---

<div class="post-metadata">

**Author:** ![schlichtanders](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/schlichtanders/32/32145_2.png) [@schlichtanders](https://discourse.julialang.org/u/schlichtanders)\
**Post date:** [June 19, 2023, 12:59pm UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/16 "2023-06-19T12:59:06Z")

</div>

Pluto is managing the environments independently for each notebook.

It might be that for some weirdness, the Pluto Notebook falls back to the global top level environment. That would be a bug at Pluto.

I am familiar with a huge part of the Pluto code base. The way environments are handled is with a temporary directory with the Manifest.toml and Project.toml of the respective Pluto notebook. So nothing really fancy going on here. It might be that if for some reason no Manifest.toml or Project.toml exist in the temporary directory, that the environment handling defaults to using the top-level environment.

But also the top-level environment is not really old - it is not my laptop which I haven’t updated for years, it is a docker container run on my cloud ([cloud.jolin.io](http://cloud.jolin.io)) with a pretty recent docker image.

* * *

Another thought: I recently enabled

```julia
ENV JULIA_PKG_PRESERVE_TIERED_INSTALLED="true"

```

for the docker, hence the new Pluto environment can interfere with other Pluto environments in that they have already been initialized and downloaded and their versions will be preferred.

Nevertheless, worst worst case, I started development on these Pluto examples in February the earliest possible, hence there still needs to be some bug how I can get a reference to such an old GR version

---

<div class="post-metadata">

**Author:** ![dlakelan](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlakelan/32/8491_2.png) [@dlakelan](https://discourse.julialang.org/u/dlakelan)\
**Post date:** [June 19, 2023, 1:21pm UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/17 "2023-06-19T13:21:34Z")

</div>

> [@lmiq](#):
>
> Pluto notebooks are completely self-contained?

Wasn’t aware, haven’t used Pluto in a couple years. If this is the case then it’s kinda odd.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [June 19, 2023, 1:35pm UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/18 "2023-06-19T13:35:41Z")

</div>

Has been like this for a while - it’s pretty cool for certain workflows (especially reproducible, self-contained notebooks for sharing), less cool for others, see:

> **[🎁 Package management](https://github.com/fonsp/Pluto.jl/wiki/%F0%9F%8E%81-Package-management)**
>
> 🎈 Simple reactive notebooks for Julia. Contribute to fonsp/Pluto.jl development by creating an account on GitHub.

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [June 19, 2023, 1:42pm UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/19 "2023-06-19T13:42:56Z")

</div>

Maybe something in the `startup.jl` file can interfere? Or not even that?

(Indeed having to install Plots from scratch on every notebook is less cool, particularly in 1.9)

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [June 19, 2023, 1:59pm UTC](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546/20 "2023-06-19T13:59:43Z")

</div>

I think Pluto deliberately disables startup files (part of their reproducibility philosophy) so probably not an issue.

[Next page](https://discourse.julialang.org/t/plots-gr-broken-after-updating-pluto-dependencies/100546.md?page=2)