Is there a way to "package" kscripts?

First off, this is an awesome project and it’s been super useful to me! Thanks for all your work on it!

I’m wondering whether there’s a way to support this use case:

• I write a script (or set of scripts) using kscript. Obviously, I have kscript installed on my computer.
• I want to share this with someone who does not have kscript installed on their computer, and have them be able to run it as well.

Right now, what I’m doing is having them install kscript (some people don’t have sdkman or homebrew installed, and they don’t like installing them).

However, in an ideal world, I would be able to instead send them a jar file (and possibly an accompanying shell script to execute the jar file), which would run without them having to install kscript.

This would be similar to gradle, accompanied by a gradle wrapper script.

Ideally, even Java would be fetched by the wrapper shell script (if they don’t have Java installed), but I suspect this is a mess not worth getting into.

I can do all of this manually by creating a gradle project, and a shadowJar, but it takes a fair amount of effort, and it would be great if that part could be automated with something like perhaps: kscript --package foo.kts.

Thoughts?

[holgerbrandl]

Gentleman, thanks to @fab1an’s pointer I’ve used https://github.com/puniverse/capsule to implement packaging of scripts.

See https://github.com/holgerbrandl/kscript#deploy-scripts-as-standalone-binaries for an usage example.

I guess there are some glitches, but feel welcome to report them. 😃

[holgerbrandl]

Interesting question. 👍

What we could certainly do is to provide a docker container for kscript containing all dependencies. But docker is even more invasive that kotlin/java/kscript, and some users would struggle with it as well. It still might be a solution for more advanced users.

So if docker does not work for somebody, we need to make at least some assumption about her setup. E.g. that there’s bash. For bootstrapping the remaining java, kotlin and kscript, I think that sdkman is actually the best tool at the moment.

So I think --package could at best combine the sdk setup, that is installing all java and kotlin, if not present on the target system, and run the app from some binary payload (which is the script’s compiler jar created within kscript). So something along:

!#/bin/env bash

if no sdkman --> install sdkman
if no java --> yes | sdk install java
if no kotlin --> yes | sdk install kotlin

MYSELF=$(which "$0" 2>/dev/null)
exec kotlin -cp $MYSELF <<other args as used normally within kscript to create user process>>
<<binary payload: the compiled jar>>

This would be script created by kscript --package 'println("foo")'.

And as you can see from the mockup, kscript would not be needed for the packaged application

For details about payloads see https://coderwall.com/p/ssuaxa/how-to-make-a-jar-file-linux-executable.

One drawback of such a solution would be that binary payloads are compatible between mac and linux, but think not with windows (afaik). The packaged kscript-apps would not work on the respective other side of the os-world.

What do you think? Reading your comment again, such a solution would be even better, because it would allow to ship just a single executable file.