The best would be to just remove the Plots package from the Julia distribution.
It is just a mess (according to the internet and all the other people with the same Qt problem and no real solution in sight).
And no I cannot install a newer Qt because in real life people often do not have super user rights and I don’t want to screw up my home directory with my own rogue /usr/bin.
When was the last time you had to worry that matplotlib on Python will not work?
Look to it from that perspective: would you develop Julia code using Plots for sharing with other people when you know that Plots may work or may not work on their platform (this does just not happen with matplotlib and Python).
using Plots
plot(and(22))
… libQt5Core.so.5: version Qt_5.15 not found (required …) …
Plots in Julia is installed on my heavily guarded Linux distro (if it were not ‘using Plots’ would already raise an error).
I thought my post explained it:
julia> using Plots
Julia> plot(rand(23))
will throw the errors:
QT not found and the GKS error message (as shown in my original post).
(It would work on my OSX Ventura and my Macbook but this is beyond the point because here I am my own super user and can always make sure the BSD is up to date with various homebrew hacks).
It is really shocking how bad and absolutely confusing and confounded Julia “Plots” is. Honestly.
I am no Linux expert. Why should I have to worry and ponder over backends.
Plots should just work straight out of the box if I install it from within Julia.
This is what conda just does: install me all the packages I ask for and make sure they work (admittedly I only have got experience using conda on OSX and Linux so there may well be configurations where conda blows up).
But there is a silver lining on the horizon: using PyCall and then matplotlib works.
For me it almost always worked, that was an exception of a very old machine. What kind of Linux are you using?
You can switch the backend using:
using Plots
pyplot()
and that may work, if the problem is with GR.
Note that Plots is not part of Julia. It is a package that attempts to unify the interface of many plotting packages, GR being one of them and the default one to load.
Be aware that infuriating as it may be, it can also be that you are experiencing a rare failure case, which may not the experience of most people. Bugs exist, and they are bugs because the developers and testers didn’t experience them first round.
(this is offtopic, of course, but I’m sure you can find thousands of people trying to find how to solve matplotlib installation issues, it just happened that you were not of them).
I hedge a bet for Python it is matplotlib that the majority will use (at least for the bog standard 2d and 3d plots).
This also means when you use other peoples (scientific) Python code you will encounter matplotlib. And matplotlib just works out of the box with conda (OSX and Linux).
I have to repeat myself: what is the flagship plotting library for Julia that is supposed to work out of the box on all the major platforms (like matplotlib installed with conda).
For me it is Plots, and I’ve been using it happily for some years now. Makie is becoming more and more important, and is quite powerful (I don´t like its load time).
While Plots is (still) probably the most used frontend for plotting, Julia does not have such a unified plotting approach, there are alternatives.
But probably you should not confound that with the bad experience you had with Plots, you probably just were not lucky (as lots of folks in the web are not lucky using matplotlib for a myriad of infuriating reasons as well).
Having a plotting library just for one programming language may cause a whole raft of other problems.
That one can use Matplotlib in Julia is not a bad choice. It is just a fact of life that Python and subsequently matplotlib is one of the dominant tools in data exploration.
Why don’t the Julia stewards declare that pyplot shall be the main Julia plotting library?
This tends to indicate either a conflict in libraries, which may be triggered by LD_LIBRARY_PATH as @lmiq pointed out or this could be the consequence of a failed download of one or more artifacts.
You didn’t post a full log of the errors (julia stacktrace). A solution might be to delete the offending artifact directory and run pkg> instantiate (but we need your logs in order to be able to help).
I understand your frustration . But, just to offer some perspective: ggplot2 is a much more widely used plotting library for data exploration in many fields. I would rather walk backwards into a cactus with a bare butt than use pyplot as my go-to plotting library. Don’t get me wrong: Pyplot is great for sure but i don’t like it and it’s really not productive for me. Long story short. I’m not sure pyplot is the preferred choice for the majority of people. So Julia marrying with a single library like that would be a bad move IMHO.
These issues do pop up from time to time, but they tend to fly under the radar because people will ask about them places like Slack (where you have ephemeral messages, lots of traffic in busy channels like #helpdesk and not many eyes on more obscure channels working against seeing such messages) or the issue tracker (e.g. 1, 2) where people who don’t have issues with plotting won’t be checking.
Now, 99% of people probably don’t have issues with the default plots backend. But if matplotlib runs successfully say, 99.9% of the time, one library will get more of this kind of issue reports than the other.
. But, just to offer some perspective: ggplot2 is a much more widely used plotting library for data exploration in many fields. I would rather walk backwards into a cactus 
with a bare butt than use pyplot as my go-to plotting library. Don’t get me wrong: Pyplot is great for sure but i don’t like it and it’s really not productive for me. Long story short. I’m not sure pyplot is the preferred choice for the majority of people. So Julia marrying with a single library like that would be a bad move IMHO.