I recently started thinking about an alternative strategy to improving the end user experience in the plotting ecosystem. Is it correct that the recipe system nowadays is decoupled from Plots.jl? For instance, could an author of a plotting package (e.g. GR.jl) implement the recipe for his/her own package using RecipesPipeline.jl? I believe that the answer is yes based on the recent developments around MakieRecipes.jl, but would like to double check with you all. Is it true that currently the implementation of backends is delegated to the Plots.jl maintainers?
I think we all understand the value of the recipe system initiated by @tbreloff a long time ago, and I think we all agree that we reached a state of affairs in the ecosystem where a reduced set of maintainers are overwhelmed maintaining all the backends in a single repository. Could this maintenance burden be split among the package authors? Could RecipesPipeline.jl be some sort of “PlotsBase.jl” with an agreed API for recipes that plot packages implement? What do you think of this proposal?
As an end user, this is a list of benefits that I can foresee with this approach:
- It would be much easier to contribute patches to specific backends.
- Authors of plotting packages would be able to review and merge patches much more quickly without worrying about breaking other backends.
- I guess time-to-first-plot would reduce? Given that users would only load a specific backend, we could avoid loading the entire system:
using Plots # loads everything gr() # select GR
in favor of loading a specific backend code:
using GR # recipes for GR ready to be used
Appreciate your thoughts on this issue.