Can you expand your functionality based on other package availability?

I want to expand a package I’ve written to provide extra functionality if another package is installed, but not to make that package compulsory. I don’t know whether it’s possible to do that, but it seems like it would be a useful thing… ideally I’d also like to put requirements on the version of the package.

I’ve tried defining functions if Pkg.installed("Package") is not nothing and/or if the version is okay, but it precompiles it once and doesn’t update if “Package” is subsequently installed:

module Expansion
if Pkg.installed("TestPkg") != nothing
    include("expandTestPkg.jl") # containing my expansion code
    export TestPkgExpansion

If I put Pkg.installed("Package") inside the function or type definition then I can’t make the function dispatch on a type only defined in the “Package”, or the type contain an element of that type.

Is there some way of doing this?

This is conditional dependency stuff. The “true solution” is in development:

Currently, you should avoid doing something like this if you precompile your package because it can have some bad edge cases. However, some packages do stuff like this (Plots.jl as the notable example) and do mostly okay.

You could also take a look at

But be warned: that package does some really non-standard stuff. It is also not very well maintained, i.e. bugs often stay unfixed for quite a while etc. I’m using it a lot, but I often wish I didn’t have to :slight_smile:

Thanks @ChrisRackauckas. I did look at Plots.jl for inspiration, but to be honest I immediately got it to crash my Julia session, which I figured was not a good sign! I also can’t really follow how it’s doing it. However, Requires sounds like what I need - thanks @davidanthoff - it’s a shame if it’s so flaky…

I suspect if this is a feature that really is coming though, then I could make the packages compulsory for now and then optional when the feature appears. I see there’s another issue about it though:

which has been bumped back from 0.4 to 0.6 and now to 1.0… is it really going to be done?

I would take this 1.0 milestone on github with a grain of salt. The current official message is still that julia 1.0 is supposed to happen at juliacon (or at least an alpha build, which I assume means feature complete). There is absolutely no way on earth that all the things that currently have the 1.0 milestone on github will be done by then, so something will have to give (either the timeline or the scope for 1.0).

Hah, yes - I wasn’t exactly expecting the fact that it said 1.0 to mean it would be done by June! My question was more - are there lots of things like this that will probably get pushed back to 2.0, 3.0, etc.? I guess the answer to that is yes by your answer…

Well, or they change the timeline… I have no insight into the thinking of the core dev group on this topic.

Plots shouldn’t crash your Julia session, you should open an issue if it does.

@mkborregaard I’m sure you’re right. I couldn’t get it to compile under 0.6, and then I tried to play around with it under 0.5 and my session bombed out. I can’t reproduce it because it wasn’t what I was trying to do - I was just trying to get to grips with how it was handling multiple potential backends, but since I failed to understand the code too I just moved on I’m afraid.

For those who are interested, I was reassured to hear when I just asked in the last thread

from Stefan Karpinski:

Yes, we really need this in 1.0 – it’s a big problem for the package ecosystem currently.