Add support for image generation via Kaleido

[alexarchambault]

The plotly authors recently released a new tool called Kaleido, allowing to generate static images locally, without a browser. It relies on a native process running in the background. We can exchange JSON messages with that process to generate images.

[alexarchambault]

cc @jonmmease. Kaleido looks neat! Thanks for having ping-ed me.

I'll look into trying to use it from plotly-scala. I guess the main hurdle should revolve around fetching the Kaleido binary from plotly-scala (as it's not too common to embed large binaries in Java libraries, we'll probably have to fetch it and cache it manually ourselves.). Don't know if I'll have the time to fully push it through.

[jonmmease]

Hi @alexarchambault, thanks for taking a look!

Whenever you're interested in thinking about this some more, let me know what if there would be a more helpful way to host the binaries. Right now I'm just including them as GitHub release artifacts.

Also, just for reference, on the Python side we're not including the kaleido binaries in the main plotly package. Instead we created a new package that only contains the Kaleido binary and a thin Python wrapper for communicating with it. The plotly package will then use the kaleido package as an optional dependency. I don't know if something like that would make sense in Java/Scala land, but wanted to mention it.

[alexarchambault]

Instead we created a new package that only contains the Kaleido binary

That approach could work for us too. We could re-package the native binaries in distinct dependencies, push those to Maven Central, and require users to add an extra dependency, like org.plotly-scala::plotly-kaleido, which would itself depend on the right dependency depending on the OS. We would also have to write the native binary, under a sub-directory of ~/.cache/… say, as the content of JARs (the JVM archives…) are not unpacked.

Right now I'm just including them as GitHub release artifacts.

GitHub release artifacts are fine, we can download the binaries from there during build time. Re-packaging them ourselves in JARs pushed to Maven Central would then allow users behind proxies / firewalls to download those JARs through whatever Maven Central mirror they have access to.

[jonmmease]

Sounds great!

Also, I'm chatting with @kMutagene over in plotly/Kaleido#2 and https://gist.github.com/kMutagene/77aca4941e89f96bdbf5700f45ff27b3 about potentially including an F# wrapper for Kaleido in the main Kaleido repository, and integrating into the CI process there. I'm not sure if we'll end up going this way, but wanted to mention that here in case it sounds like this approach would be easier on your end.

[johanneshiry]

Hi @alexarchambault
I came here while searching for a plotly-scala library with static file support. Has there been any progress with the Kaleido integration? Has the work on this started already and is currently someone actively working on this?

[johanneshiry]

fyi - I spent the weekend to work on a scala Kaleido wrapper - first working version can be found here -> https://github.com/johanneshiry/kaleido-scala

currently only supports pre-downloaded binaries and has a hard coded link to the binary. I will work on the following within next weeks:

• automatic binary download depending on the OS
• minor fix to improve error logging / kaleido handling (seems like I cannot kill the process everytime)
• tests
• support for kaleido > 0.0.3

@jonmmease for the support of kaleido binary > 0.0.3 I have a question: whenever I execute another binary with version > 0.0.3 on macOS Big Sur (manually and via scala code) I end up in a dead loop with the following ouput:

[0425/224218.091457:ERROR:network_service_instance_impl.cc(286)] Network service crashed, restarting service.
[0425/224218.122215:WARNING:resource_bundle.cc(431)] locale_file_path.empty() for locale en-US
[0425/224218.122316:FATAL:content_main_runner_impl.cc(810)] Check failed: sandbox::Seatbelt::IsSandboxed(). 
0   kaleido                             0x0000000106cb56e9 base::debug::CollectStackTrace(void**, unsigned long) + 9
1   kaleido                             0x0000000106bed2d3 base::debug::StackTrace::StackTrace() + 19
2   kaleido                             0x0000000106c02e8f logging::LogMessage::~LogMessage() + 175
3   kaleido                             0x0000000106c03cee logging::LogMessage::~LogMessage() + 14
4   kaleido                             0x000000010689c7e9 content::ContentMainRunnerImpl::Initialize(content::ContentMainParams const&) + 777
5   kaleido                             0x000000010689b97d content::RunContentProcess(content::ContentMainParams const&, content::ContentMainRunner*) + 2333
6   kaleido                             0x000000010689ba9c content::ContentMain(content::ContentMainParams const&) + 44
7   kaleido                             0x000000010693071e headless::(anonymous namespace)::RunContentMain(headless::HeadlessBrowser::Options, base::OnceCallback<void (headless::HeadlessBrowser*)>) + 302
8   kaleido                             0x000000010693054d headless::RunChildProcessIfNeeded(int, char const**) + 301
9   kaleido                             0x000000010367731c main + 28
10  libdyld.dylib                       0x00007fff20648621 start + 1
11  ???                                 0x000000000000000a 0x0 + 10

Do you have any idea why this happens? Is this a known issue and I just oversaw something? If not, I will hand an issue in the kaleido repo.

[alexarchambault]

@johanneshiry Nice! Feel free to mention your project in the README of plotly-scala, or even add a whole section about it there, whenever you think it's ready.

[johanneshiry]

Okay I'll let you know. Considering the deployment to maven. Any chance to get access to the namespace org.plotly-scala in order to deploy the kaleido artifact there? I think adding kaleido to the same namespace as a plotly module would be helpful for everyone that wants to use the module?

[jonmmease]

Hi @johanneshiry, very cool!

I think the error you're getting is related to chromium sandboxing. In 0.0.3, we hardcoded a few chromium flags in the bash script that launches kaleido (including --no-sandbox). In later versions, we made the chromium flags configurable through the Python API. Here's is the default set the Python API uses if you want to just hard code them for now:

--no-sandbox --disable-gpu --allow-file-access-from-files --disable-breakpad --disable-dev-shm-usage

These can be passed directly as flags to the kaleido executable. Hope that helps!

[johanneshiry]

Perfect thank you :-)

[johanneshiry]

@alexarchambault the first release is almost ready for scala 2.12 and scala 2.13 - before I'm going to deploy this on another namespace, is there any chance that I can get access to deploy tot he org.plotly-scala namespace in order to have all libraries at the same place? I think this would be a more convenient way for people to find the library. Otherwise I would publish it somewhere else ...

[johanneshiry]

@alexarchambault would you mind providing an update on my last question? We started working on this internally and kind of rely on the kaleido features. Before we're going to deploy it somewhere else it would be nice to hear you thoughts/feedback on the possibility to deploy it under the same namespace!?

[alexarchambault]

@johanneshiry Sorry. Do you have a Sonatype user name already? I can open a ticket, asking for you to get the right to publish under org.plotly-scala.