Hi all! Is there a way to specify different versions of the same package in [compat] based on the OS of the computer running the package?
I’m working on a team to develop a package which has a custom plotting script in it (using PlotlyJS), and while I am running on a Mac, another collaborator is running windows. There is an issue with Kaleido_jll that is resolved on windows by pinning the version to 0.1.0, so my collaborator used [compat] in the Project.toml to pin Kaleido_jll to that version. The problem is that this breaks PlotlyJS for me unless I allow Kaleido_jll to go to version 0.2.1
Is there a way we can resolve this elegantly? Thanks!
The best long-term solution is to submit a PR upstream to Kaleido that fixes the issue and then update the compat bounds in your package to disallow earlier (buggy) versions of Kaleido.
This is unfortunately not so easy for the specific case of Kaleido.
The original Kaleido repository currently works by providing a relatively lightweight binary that can read the plot object from stdin and produces the figure content as output.
Unfortunately the library has been stale since some years and is currently going through a significant rewrite which will be based on a python only wrapper that assumes chrome or chromium to be installed locally (see this error here).
This means that the eventual new version of kaleido will not be usable anymore using the artifact systems and binary builder (unless serving the chrome executable that way instead of the smaller kaleido binary).
I wonder if at this point it might be worth in the PlotlyKaleido.jl wrapper to use an ad-hoc copy of the Kaleido_jll 0.1 binary for windows to use on windows systems while still allowing other systems to use the more up to date version of the Kaleido_jll artifact
Agreed, with kaleido’s new design, I’m not sure if that could work in Julia with jll’s (besides wholly implementing in Julia/with jlls).
On the off chance this is an XY problem, the plotly/kaleido documentation has never explicitly stated that kaleido is only needed for image generation in browserless contexts. If you are displaying plots in a browser (e.g. Jupyter or Blink), you might also investigate calling the javascript toImage functions directly (which is ultimately what Kaleido does afaict). The PlotlyJS package has a to_image(plt::SyncPlot; kwargs…) function that might[1] work for you.
tl;dr The plt["image"] observable can’t update until after the Jupyter cell finishes execution, so that function must be called at the end of a cell before you can access the new plt["image"] value in a subsequent cell. I am in the process of developing some fixes, but it involves some substantial architectural changes to IJulia and won’t be arriving anytime soon (if ever). ↩︎
No. The package manager specifically doesn’t allow that, to make package resolution platform-independent, which makes Manifest portable everywhere. The feature you ask would of course be more flexible, but at the cost of making package resolution more complicated and manifests non-portable.
This very well could be could be an XY problem, but I’m not displaying plots in a browser in this case. My main use case is to generate the plots without displaying and then save them to .png
Using Kaleido_jll version 0.1.0, the first time I call using PlotlyJS in the REPL, I get an error ERROR: InitError: UndefVarError: 'kaleido' not defined (coming from src/PlotlyKaleido.jl:79). The second time I try using PlotlyJS in the REPL it will work, but as soon as I try to use the savefig() command, I get a similar error ERROR: UndefVarError: 'kaleido' not defined (also coming from src/PlotlyKaleido.jl:79). The only way I found to resolve this was to allow Kaleido_jll to go to version 0.2.1
So perhaps the solution is actually more like what @disberd described:
I wonder if at this point it might be worth in the PlotlyKaleido.jl wrapper to use an ad-hoc copy of the Kaleido_jll 0.1 binary for windows to use on windows systems while still allowing other systems to use the more up to date version of the Kaleido_jll artifact
I encourage everyone to try this out prior to me merging it, since I don’t have a windows machine to test. For that regard I am giving it a week before I merge.
Agreed, with kaleido’s new design, I’m not sure if that could work in Julia with jll’s (besides wholly implementing in Julia/with jlls).