How to take advantage of Weak Dependencies?

[jkrumbiegel]

There's a new feature in Julia coming up which allows to specify weak dependencies for a package. That's basically the sanctioned way of what was previously done with Requires.jl but it's better integrated and doesn't break precompilation.

Downstream packages are expected to use this going forward to implement Makie plotting functionality without taking on full dependency on it. But can we also improve Makie loading times by factoring out some functionality? I'm not sure, as I think a plotting package would be expected to work fully without installing additional packages to "unlock" something like contour plots (contour plots were the example used in the documentation of the new feature).

[fatteneder]

Do you mean by Weak Dependencies the Package Extensions feature from the master docs? https://docs.julialang.org/en/v1.10-dev/manual/code-loading/#man-extensions

The MWE on the doc page seems that is a feature that provides better support for mono repos via Pkg.jl.
So the only immediate application I can think of would be to convert backends into Pkg extensions. But that might not bring any benefits and will only mess with the release workflow.

[jkrumbiegel]

No the purpose is to split out functionality from the main package into a submodule that only gets loaded if some other packages have also been loaded by the user. Thereby avoiding the overhead of the dependency for all but those that installed it separately.

For example, making plot(::HistogramFromStatsbase) work only if someone has already installed StatsBase. But I haven't come up with anything yet that I'd think would be good to split off from Makie, also because I guess people would be confused if some functions stopped working, one would have to document what's going on very clearly and obviously.

[fatteneder]

ups my bad, I totally ignored the text when reading the MWE ...

[bilderbuchi]

I have found two candidates for the package extension treatment in #2683:

I noticed that I'm pulling in an FFMPEG dependency via Makie.
Also, the (largeish) MKL is pulled lazily in via MKL <- FFTW<-KernelDensity<-Makie.

I'm not including video playback features, so I thought it should be possible to not install FFMPEG. However, this is used in the Makie module, which is of course centrally used everywhere. Similar with the MKL - it would be great to avoid that if I'm not using violin or density plots.

The MKL case is compounded by the fact that MKL_jll depends on LazyArtifacts, which needs Pkg, which pulls in a large number of other dependencies. Now that binary dependencies do not need Pkg anymore, LazyArtifacts is (in the medium run) the only package in one of my projects that drags in Pkg. This is relevant when using PackageCompiler.

[SimonDanisch]

I'd love to use extensions more, but I'm also a bit worried that it will decrease usability...

Maybe we can revisit our dependencies and make some notes for each?
I think some are very well fitted to use extensions without usability problems (e.g. when plotting a type from some package), but others taking generic input types like arrays will be harder to move out.

[bilderbuchi]

I'd love to use extensions more, but I'm also a bit worried that it will decrease usability...

[...]others taking generic input types like arrays will be harder to move out.

If I understand correctly, the usability problem when using extensions would be that people wanting to e.g. make a density plot would then need to (know that they) need to manually load KernelDensity.
There is a change incoming that allows to load extensions from within package code: JuliaLang/julia#49990. If I understand correctly, it seems like this could be used to avoid this usability issue around loading. Thus, what remains is just telling people that they need to install KernelDensity if they want to make density plots (and similar for other optional features).