-
-
Notifications
You must be signed in to change notification settings - Fork 358
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
select Plots
backend via Preferences
(or env variable)
#4566
Conversation
Preferences
Plots
backend via Preferences
(or env variable)
b03ec13
to
86a1062
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the special case of GR, should we do import GR
within the top-level of Plots if it is the default backend?
Perhaps we should consider a more radical redesign in the near future?
- Each of the pieces of backend glue code could be independent subpackages. GRPlotsBackend, PyPlotPlotsBackend, etc.
- Most of the code currently in Plots.jl gets moved to a package named AbstractPlots.jl. All the backend packages depend on AbstractPlots.jl.
- Plots.jl becomes a small package which just depends on GRPlotsBackend.jl by default. Via Preferences.jl it can optionally load any of the other backend packages and act as a proxy for that package.
The advantage of this is that each backend now can be precompiled and has its own compiled cache. Also the project dependency tree becomes a bit clearer. One could get all the features of Plots by just doing using SomePlotsBackend.jl
directly.
For loading with Requires.jl can then just do @eval using GRPlotsBackend.jl
similar to what @timholy recommended here:
https://discourse.julialang.org/t/categoricalarrays-forces-openspecfun-jll-recompilation/87759/18?u=mkitti
The impact here for this PR is still acknowledging that the GR backend is a special case for the current architecture. That is Plots.jl has declared a dependency on GR.jl. One consequence of that special case is that we load GR.jl within Plots.jl rather than Main. Eventually we move that responsibility to GRPlotsBackend.jl.
This PR removes that, in order for users not wanting to use the default backend to not load $ JULIA_PKG_PRECOMPILE_AUTO=0 julia -e 'import Plots; Plots.set_default_backend!(:unicodeplots)'
$ julia # restart, to show persistent mode
julia> using Plots
julia> plot(1:2) # uses `UnicodePlots`
[...]
julia> using Libdl
julia> any(map(x -> occursin("libGR", x), Libdl.dllist())) # check that we didn't load `GR`
false
julia> exit(0)
$ JULIA_PKG_PRECOMPILE_AUTO=0 julia -e 'import Plots; Plots.set_default_backend!()' # clear `Preferences` key without ever loading
Thanks for the valuable comments here.
I haven't though of that, and its a clear advantage. However, usually, the common scenario is sticking to a backend (everyone has its preferred backend, and usually only use a single one). So in practice, precompilation for a single backend might be sufficient to cover
Wouldn't the load time be increased, since you parse to evaluate the common
This is a good idea for the long term, we'd have to export a lot of symbols from this module. This also enhances composability. Overall I think this is the plan for the long term (let's open an issue about this specific re-design ? EDIT: #4567), but for the moment I'd like to be the least disruptive and try this out. |
e76bee6
to
3f28b5b
Compare
Codecov ReportBase: 90.76% // Head: 90.64% // Decreases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #4566 +/- ##
==========================================
- Coverage 90.76% 90.64% -0.12%
==========================================
Files 41 41
Lines 8488 8756 +268
==========================================
+ Hits 7704 7937 +233
- Misses 784 819 +35
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
c84c7ff
to
a7bbc94
Compare
d294a09
to
5f59f88
Compare
fcf0152
to
136064a
Compare
Thanks for the comments and the help here. |
My pleasure. So are we dropping pyplot support? That is breaking, no? |
No, it will still supported for plots 1.x, but no more development and bug fixes. Seems acceptable no ? Maintaining both is a lot of work ... Edit: I plan to make a discourse announcement for Plots |
This seems to have broken e.g. PGFPlotsX:
Reported at KristofferC/PGFPlotsX.jl#308 |
Apparently, this line is not effective for some reason? Line 1370 in 62c1407
|
I can't reproduce that. Which version is that? |
The following is the repro:
Plots 1.38.3 |
Hmm.. so the issue seems to be loading |
Removing using Plots
using Plots.PlotMeasures
using LaTeXStrings
using DelimitedFiles
pgfplotsx(size=(900,900), legend=true,grid = false,framestyle =:box,xlim = (1.1,5.3),ylim = (-0.1,3.0),xminorticks=2,yminorticks=2) |
Fix #4513.
Supersedes #4517 (borrows the added test).
This PR:
PLOTS_DEFAULT_BACKEND='unicodeplots'
or make it persistent viaPreferences.jl
, e.g.Plots.set_default_backend!(:unicodeplots)
, all case-insensitive;ttfp
for nonGR
backends;GR
runtime problems (low-levelc
, sinceGR
is conditionally loaded);Requires
(making this PR non-breaking);Plots.diagnostics
function.We cannot remove the hard dependency on
GR
inProject.toml
since it would be breaking, but it would be trivial to moveGR
from[deps]
to[extras]
inPlots 2.0
.One would then have to type
Pkg.add(["Plots", "<mandatory chosen backend>"])
to usePlots
, which I think is acceptable to ask and has the benefit of reducingPlots
dependencies imprint (you won't have to downloadGR
(and thus artifacts) if you chose to stick to another backend).Ping @BeastyBlacksmith and @mkitti for discussion / review of the implementation.