What I meant is was that in Python-numpy land matplotlib is the major player.
I have never met anyone who actually likes matplotlib but this is what is mainly being used when people use numpy.
Personally I never liked the appearance of R plots. I know a lot is personal preference. The best looking plots produced the IDL data language (although most would disagree with me on that point).
Hey @Schneeschaufel — I totally get your frustration. This is something that the Plots.jl (and GR.jl) folks try very hard to make work out of the box for everyone. And yes, in rare situations it doesn’t work. If you want to debug the problems and try to smooth it out (for yourself and potentially others who come after you), folks are already trying to help you do so right here. Simply saying that Plots has a lot of problems on a given platform is not helpful — most of us do not encounter lots of problems on a regular basis.
The only thing special about “Plots” is its name. It’s not specially blessed by the Julia stewards (who really just help set community standards) nor the core language developers. You’re free to use PyPlot, Makie or any other library. If your administrator has chosen Plots as the one and only plotting package available to you on your locked-down system, you should bring that up with them.
I think you have misunderstood what the goal of the Julia stewards is. You can read about stewardship here Julia Community - Stewards. Declaring what is the “main Julia plotting library” is not really one of their tasks ;).
Like the others I’ve never had issues on this across several linux and windows systems, but these things do occur for some people. The great thing about Plots is that it is only a front end with unified syntax for several backends. If you want matplotlib, just add
using Plots
pyplot()
And you can choose the one which works best for you, without having to learn a different syntax for each plotting library. If Plots isn’t what you want, Makie (split between CairoMakie or GLMakie) is a good option too, especially if you want high performance plotting.
Also, if you are able/want to use VS code with the Julia extension you have access to the inbuilt plotting pane, which bypasses the need for creating a separate window and might help solve your issues.
May be the “homebrew hacks” (and a changed DYLD_LIBRARY_PATH) are the cause of the problems - same for Linux (LD_LIBRARY_PATH). You could update GR.jl to v0.70.0 and set GR_DEBUG=1 and then ] test GR to get more information.
Maybe I spend a bit more time the weekend. But as long as pyplot works it is okay.
Nothing to do with OSX homebrew because I am on work Linux (which is heavily guarded for security reasons).
I also don’t think it is conda. I know no one wants to hear it but I installed Julia (on my work Linux) with conda in a virtual environment. I think it works.
What people often forget: Linux its also used in real life which sys admins. But this also means (especially in a heavily guarded environment) it is not easy to install things (e.g. newer Qt) on the fly /usr/bin (except in own /home). On my own Macbook and OSX I can do what I want.
The recommended way to use Julia is to use the binaries from the website, not through anaconda. From there, it has it’s own built in package manager, with “environments” (see 4. Working with Environments · Pkg.jl), which work a bit differently than conda.
You can use the binaries without the need for installing them with sudo, just download to your home directory and unzip the archive. There’s a binary in the bin folder which you can run to use julia. I usually add the bin directory to my path so I can just run julia without specifying the path. All of this can be done without any special permissions, and it done often on HPC systems where users don’t have admin access.