Fix compilation failure on Julia 1.10

[MilesCranmer]

Julia 1.10 requires that no I/O resources are left open during module initialization. Thus, the code:

__init__() = start()

needs to be removed, and the user must call

PlotlyKaleido.start()

manually upon initialization.

I have implemented these changes. I have also updated the package version to 2.0 so that this does not introduce breaking changes in any existing dependent projects (though they will soon break anyways).

I also fixed a bug where kill() is defined incorrectly, as it conflicts with Base.kill(). It is now kill_kaleido.

Fixes #5

@BeastyBlacksmith would you be willing to merge this relatively quickly? This is currently breaking my package AirspeedVelocity.jl on Julia 1.10.

[BeastyBlacksmith]

I am okay with that. @joshday, what is your opinion?

[joshday]

I don't like that you have to separately call PlotlyKaleido.start() but if it's unavoidable then it's unavoidable. LGTM

[MilesCranmer]

Thanks, please merge when ready. Indeed it is a hard requirement of Julia 1.10, otherwise precompilation of downstream packages will hang [source]:

If you open an I/O resource during module definition, you now (Julia 1.10+) have to close it before exiting the module. Example of a fix:

• Close timers in ondestroy JuliaGizmos/GtkObservables.jl#46

• followed by more thorough housecleaning during precompilation: More explicit finalization JuliaGizmos/GtkObservables.jl#47

I can't remember if the 2nd PR was needed to fix precompilation, but I don't think so. But digging turned up more evidence that we were doing a bad job of freeing resources, so responding to the changes in 1.10 made the package better.

[KristofferC]

An alternative is perhaps to only run it when precompilation is not happening?

[timholy]

What's tricky is that it doesn't affect precompilation of PlotlyKaleido, because during precompilation we don't call __init__. (Maybe we should, though.) Instead, __init__ only gets called by packages that use PlotlyKaleido. And they'd have to be responsible for killing it.

But thinking about it again, I guess you're proposing that the __init__ checks if we're precompiling, and indeed that would fix the problem for all precompilation.

[BeastyBlacksmith]

guess you're proposing that the __init__ checks if we're precompiling,

How could we do that?

[timholy]

Magic incantation: ccall(:jl_generating_output, Cint, ()) == 1

[MilesCranmer]

PyPlot.jl uses this trick but somehow it still runs into the I/O issue seen here: https://github.com/JuliaPy/PyPlot.jl/blob/343430ac4f822a84a5e19bf5dabf7a846b171c9b/src/init.jl#L171-L209

JuliaPy/PyPlot.jl#572

[KristofferC]

PyPlot.jl uses this trick but somehow it still runs into the I/O issue seen here:

I mean, either the code that starts the process runs or not. So are you saying it still runs even with that guard?

[MilesCranmer]

I haven’t debugged the details so I can’t answer. But PyPlot.jl does have the I/O issue and I couldn’t find any other I/O resources other than what’s in that __init__ and protected by that guard.

[timholy]

I'll tackle this (but not today), I want to write up a little guide on how you debug these things as I go.