How to package the kaleido executable

[kMutagene]

Hi there @jonmmease , thank you for reaching out, i really appreciate it!

Adding a lightweight F# wrapper for kaleido seems to be pretty straightforward, but how exactly should one package the kaleido executable?

To incorporate Kaleido in the .NET ecosystem one would have to provide a Nuget package. Is it better to include the executable in the package (am i even allowed to do that license wise?), or will you/the plotly org host the kaleido executable as standalone package that can be consumed from the wrapper?

[jonmmease]

Hi @kMutagene,

I don't have first-hand experience with .NET packaging, but here are some more detail on how things will work for Python.

We will build a Python wheel package separately for each operating system/architecture (64-bit Linux, Windows, and MacOS to start). These packages will all contain identical Python code, but they each bundle the appropriate executable for the particular operating system. Where here "executable" is really a directory with a top-level script named kaleido/kaleido.cmd.

At minimum, we'll zip up these executable directories as release artifacts here on GitHub. For example, the 0.0.1rc1 executables are attached to the release at https://github.com/plotly/Kaleido/releases/tag/v0.0.1rc1. And they can be downloaded as zip files using these URLs:

• https://github.com/plotly/Kaleido/releases/download/v0.0.1rc1/kaleido_linux-0.0.1rc1.zip
• https://github.com/plotly/Kaleido/releases/download/v0.0.1rc1/kaleido_macosx-0.0.1rc1.zip
• https://github.com/plotly/Kaleido/releases/download/v0.0.1rc1/kaleido_win-0.0.1rc1.zip

As soon as we make the repo public (I'm thinking that this will probably be the end of the week), a build script could use these URLs to download the executables.

And license-wise you are free to bundle these executables inside Nuget packages, subject to the MIT license requirements. The easiest thing is probably to just include a copy of https://github.com/plotly/Kaleido/blob/master/LICENSE.txt file with the package.

I don't know if this would necessarily make things easier, but I'm also open to including other language wrappers in this repo. Then we could build these packages as part of the same Continuous Integration workflow as the Python packages.

[kMutagene]

I don't know if this would necessarily make things easier, but I'm also open to including other language wrappers in this repo. Then we could build these packages as part of the same Continuous Integration workflow as the Python packages.

This would definitely make it easier for the wrapper to stay up to date with kaleido, but add some overhead aswell. Not sure where to go here, but i think i like the idea of this repo being the central place where the wrappers are located more.

However, i could also imagine adding packaging of the kaleido executable to this repo and consume that package from a separate project.

But first things first, ill implement a POC wrapper using the 0.0.1rc1 release executable and i think we will see where to go from there and how the maintainers from other repos decide to approach it.

[jonmmease]

Sounds good @kMutagene. Having a POC in another language will be helpful just in terms of having something more concrete to talk about. Looking forward to it!

[kMutagene]

I uploaded a small F# POC script via GIST here.

[jonmmease]

Very cool! If I have a chance soon, I'll try to see if I can get it up and running 🙂

[jonmmease]

I think this is established for the time being. Releases are included as zip files in GitHub releases https://github.com/plotly/Kaleido/releases. Going to close, but happy to reopen if there is anything actionable that would improve the situation for folks.