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?
begin
import Pkg
Pkg.build("GR")
end
Error building `GR`:
tar (child): downloads/gr-0.49.0-Linux-aarch64.tar.gz: Cannot open: No such file or directory
uninstalling and reinstalling seemed to have helped…
UPDATE: I also deleted the artifact folder following this other discourse thread. 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?
Most recent version of GR is 0.72, but you were trying to install 0.49, which is over 3-year old.
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.
More likely crowded environment?
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).
It seems this could be the right direction of solving it:
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.
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).
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).
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.
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.
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.
There are two problems:
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.
Doesn’t Pluto notebooks are completely self-contained?
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) with a pretty recent docker image.
Another thought: I recently enabled
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
Wasn’t aware, haven’t used Pluto in a couple years. If this is the case then it’s kinda odd.
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:
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)
I think Pluto deliberately disables startup files (part of their reproducibility philosophy) so probably not an issue.