Add support for Proguard when packaging scripts

[rossbacher]

• Use shadow to package "fat" jar when using Proguard.
• Allow scripts to add specific Proguard configurations via annotations.

Requires: kscripting/kscript-annotations#4

This is missing tests and I put this up as a "balloon" to see if you are interested in this.

We are seeing packaged scripts becoming really big quickly (we have scripts that package to over 20mb binaries) and with running Proguard we can reduce that size significantly.

e.g. we were able to "shrink" one of our packaged scripts from ~8MB executable size to under 3MB executable size without even spending time on writing a better config.

[holgerbrandl]

Thank @rossbacher for the PR.

Personally, I have never used the packaging option. The regular compiler cache sitting under .kscript was always sufficient enough for me and I never minded the initial setup bits to get kotlin up an running. Also, when not packaging scripts but rather relying on kscript's build cache, the builds are typically very small (and the dependencies are shared via the local .m2 index)

Although kscript is clearly a build tool, it was never intended as a full replacement for gradle or similar where more complex builds including proguard shrinking etc could be defined. So, personally I'd be more inclined to not merge your PR for sake of simplicity and maintainability.

[elihart]

@holgerbrandl I agree scripting should not be a full replacement for gradle projects, but we have developed many use cases for rather complex tools that work better as scripts than as gradle projects. In particular I think packaging them is very helpful for large teams, such as dozens or hundreds of engineers using shared tooling.

In this case it can be a headache to ensure everybody has kscript/kotlin installed and is on the same version. Additionally, for tooling that is run frequently it is more performant to run it from a binary instead of needing to compile it, even from cache. Then there are other considerations, such as network connectivity requirements, maven being down, or other edge cases.

In short, your points are very valid for smaller projects or personal use, but when optimizing for speed and robustness for large projects and teams providing a script as a minimally sized binary can be very valuable.

[rossbacher]

@holgerbrandl I agree with the reasoning that this is not going to be a replacement for gradle, but I think you can agree that it is a great tool to build command line tools (which we mainly use it for).

The --package option creates a great way to create those CLI tools and as @elihart mentions there are considerations about their size, especially if they need to be distributed and run on machines that might not have the setup to compile the scripts.