Utilizing weakdeps/extensions

[aplavin]

I wonder what the Makie devs think about embracing julia package extensions for various deps? Aside from reducing compilation/loading times, these may in practice help cleaning up the overall design.

Those that immediately come to mind are Distributions, OffsetArrays, Unitful – these probably can be made weakdeps without any changes to the interface. There are a few more that are relatively heavy, but less straightforward to remove: eg KernelDensity that is used in some recipes.

[asinghvi17]

OffsetArrays is already pulled in by the image ecosystem, so there's no point removing it. Distributions and Unitful could possibly go into extensions though, especially since the Unitful support seems to be more or less isolated to one file.

The only potential issue that I can see is supporting older versions of Julia. Introducing Requires would have a pretty bad effect on load time...

[aplavin]

The only potential issue that I can see is supporting older versions of Julia. Introducing Requires would have a pretty bad effect on load time...

Oh I definitely think it shouldn't use Requires in any case. Either only support Julia 1.9+, or keep strong deps before 1.9.

[aplavin]

I looked at Makie heavy deps, and all/most of them are currently used in a manner that doesn't mesh well with switching to weakdeps. For example, KernelDensity is among the heaviest, and it's currently used in the density() recipe.

I wonder what do you guys think about making it and other deps weak, so that the user has to do using KernelDensity if they want density() plots? Same with Distributions + qqplot, DelaunayTriangulation + tricontourf and some other.

This change would greatly reduce Makie size and installation time and I believe is generally beneficial to users. Potentially, MakieFull.jl can be created that just loads Makie and all these packages (as Makie does now) without doing anything else.

[DanielVandH]

I like the idea of having something like a MakieFull.jl for that. It might be easier on the user to have Makie itself be the package that brings everything in, and then some MakieReduced (with a better name :-)) that loads what is needed (so that Makie does using X and then using MakieReduced). I imagine a lot of scripts would be broken otherwise (obviously there is SemVer for this purpose, but it might still be a burden). The problem with this being that it would probably be very annoying to do cleanly.

DelaunayTriangulation + tricontourf and some other.

This would be nice. DelaunayTriangulation is also used for triplot and voronoiplot, but I don't know how much those are used compared to tricontourf. I think from some of my discussion with Simon, DelaunayTriangulation.jl especially was probably a bit of a mistake to include directly here rather than as a package extension just inside DelaunayTriangulation.jl itself. The coupling has turned out to be annoying at times.

[aplavin]

I'm fine with either decision, either

• Makie is lighter with extensions for fancy functionality, MakieFull is Makie + all deps
• MakieLight is lighter with extensions for fancy functionality, Makie is MakieLight + all deps

Personally, I think the first one is more natural. And for the majority of users who only use simple plots its result will just be "Makie compiles and loads faster" :)

I imagine a lot of scripts would be broken otherwise (obviously there is SemVer for this purpose, but it might still be a burden). The problem with this being that it would probably be very annoying to do cleanly.

Indeed, this kind of change is obviously breaking, and requires a new version. Although, I think it's much easier to communicate it cleanly compared to other breaking changes (such as the recent switch from convert_arguments to expand_dimensions) – users who try eg qqplot() will see an error saying "please execute using Distributions to use qqplot()". It clear and unambiguous what exactly to do.

[DanielVandH]

users who try eg qqplot() will see an error saying "please execute using Distributions to use qqplot()". It clear and unambiguous what exactly to do.

I forgot about this obvious option 😅 . I think with this it would be a good idea. Any breakage is easy to fix with this type of error message.

MakieFull is probably better with that in mind. I only ever do using (Backend)Makie rather than using Makie but I don't think using MakieFull, (Backend)Makie would be too bad if I want everything.

[aplavin]

Yeah, backends like CairoMakie or GLMakie definitely shouldn't depend on MakieFull – that would lose the whole point of reducing deps :)

Let me know if this idea is supported by Makie devs, if so I myself can start moving deps -> weakdeps.

[DanielVandH]

There is a related issue here https://github.com/MakieOrg/Makie.jl/issues/2505

[bilderbuchi]

I wonder what do you guys think about making it and other deps weak, so that the user has to do using KernelDensity if they want density() plots? Same with Distributions + qqplot, DelaunayTriangulation + tricontourf and some other.

Since #2505 was converted into a discussion for some reason, let me harvest another potential candidate from over there to this list: FFMPEG could be a weakdep to avoid dragging it in if you don't plan to use video playback.

[ffreyer]

We want issues to be things that we can directly address and eventually close, so I'm moving the ones that are more open ended, e.g. plans and discussions for changes

[bilderbuchi]

OK -- they are marked "Done" by your automation, though, which seems confusing to me at least, as this does not seem to reflect that status? https://github.com/orgs/MakieOrg/projects/5/views/1 😕

I hope you'll manage to keep an overview, I find the Discussions interface confusing and suboptimal to retain a grasp on things 😅 , things just tend to get lost in there -- in Issues you can at least tag and milestone appropriately..

[ffreyer]

I don't think I have control over that. Github just does that when I convert to discussion