Makie and Plots recipes

Specific Domains Visualization
, ,
1

I’ve got an old package (TreatmentPanels.jl) to wrangle data sets into shape for specific use cases in other packages, and as part of this have defined some Plots.jl recipes to visualise the data.

Over the last year or so I’ve been transititioning most of my day-to-day plotting to Makie, and so I’m considering adding Makie recipes to the package as well.

Now I’m wondering what to do with my Plots recipes? I recall that when Plots was first developed, the aim was for the recipes system to be plotting library independent, but I don’t think this ever materialised. Equally I think Makie recipes originally were meant to be compatible with Plots recipes but afaik that also didn’t happen.

So the question is should I provide two sets of recipes (so both Plots and Makie users can easily plot stuff in my package, with the customization syntax they are used to), or are there any issues with this (apart from maintainability burden)?

1 Like
2

If someone was motivated, it would be possible to make a Makie backend for Plots, it’s just a plotting library so there’s no reason why that wouldn’t work on some level comparable to PythonPlot or GR. We just never did so, partly because Plots doesn’t know about Observables, so for good interactivity you’d always have to used Makie directly, anyway. The code of the attempt is still in the Makie repo for some reason Makie.jl/MakieRecipes at master · MakieOrg/Makie.jl · GitHub

I don’t think Makie recipes were ever intended to be Plots compatible, they share a name but other than that the mechanism is too different.

For your last question, I think some people are using functions that take a plotting library as an argument, to dispatch to either Plots or Makie code, for example, rather than offering plot_something_makie and plot_something_plots.

1 Like
3

I might have misunderstood discussions and they happened a long time ago, but e.g. here’s a post from Michael expressing disappointment at the move away from Plots-recipes-compatibility (implying that at some point this was intended). In any case it hasn’t happened so we are where we are.

Do you have an example for taking plotting library as an argument? I haven’t seen this before, would it basically be (very simplified):

plot(lib::Module, data) = lib == Plots ? plot_plots(data) : plot_makie(data)
4

I think it was severely underestimated at the time how much work Makie would still need to cover the features that Plots’ existing backends were covering (I mean they were already talking about replacing Plots with Makie at that point). And in the time it took to flesh all of these things out, the compatibility with Plots recipes was not a deciding factor because as Simon said in that thread, he wanted to make his own recipes mechanism anyway, and decide later which was better for end users. Now, the landscape is of course quite different than it was then.

1 Like
5

The plotting library agnostic layer for Plots recipes is RecipesPipeline.jl. @asinghvi17 had some basic recipes working with Makie at some point.
In the end it’s not much different from writing a backend for Plots.jl, but you could keep the Code in your repository and tweak defaults and stuff.
But it’s also basically untested how good things work out in practice.

1 Like