Bonjour, how do you distribute on multiple platforms a CLI tool written with Kotlin-native? Last tim...

# kotlin-native

[jmfayard]

Bonjour, how do you distribute on multiple platforms a CLI tool written with Kotlin-native?
Last time I checked it was easier to publish via Kotlin-JS on npm...
Or do you use your custom brew tap?

[jmfayard]

Here is what I did last year
https://github.com/jmfayard/kotlin-cli-starter

[mbonnin]

I guess this is more a question for #cli but the audience there is super limited so here is certainly better 👍.
Overall, my favourite solution so far has been shipping a small *.main.kts file that wraps the cli. More recently, I've had some success with HomeBrew. But this is obviously only macos...

[mbonnin]

@Big Chungus has been exploring a npx equivalent for Kotlin clis (cf gradle community discussion)

[mbonnin]

I wish there was something more simple but looks like npm is still your best bet when it comes to cross-platform distribution

[jmfayard]

I have seen the kscript <http://example.com/xxx/script.main.kts> thing
but I would like to call my tool frequently with just $ goto
I think I will try brew + install.sh for people on Linux

[mbonnin]

I've been contemplating the idea of doing "distribution as a library". Basically something like:
• a minimal install.sh shell script that you can pipe from curl and:
◦ selects the correct distZip for a given architecture
◦ unzips it.
◦ calls it in bootstrap mode ./mycli bootstrap
• ./mycli bootstrap would then:
◦ set the PATH
◦ set the autocompletion
◦ run any other install hooks
• Later on, ./mycli update would perform selfupdate

[mbonnin]

The beauty of this is that it doesn't need a separate package manager, it's all standalone. Just requires a ~/.mycli folder where to do the install

[jmfayard]

that works if we never need to add features to install.sh
but if do then we won't be able to modify all forks of install.sh
and regret to not have a proper package manager

[jmfayard]

I think I would prefer kscript install jmfayard/kotlin-cli-starter

[jmfayard]

obviously that's a lot of work so I will try brew in the meantime

[mbonnin]

Still requires your users to install kscript

[mbonnin]

While curl is on each and every computer

[jmfayard]

yes but each language community has its package manager, there is probably a good reason for that 🙂

[mbonnin]

Except Kotlin 😞

[jmfayard]

let say you want to auto-configure shell completion
then you have to reinvent the wheel in install.sh
while brew and clikt have you covered

[mbonnin]

That's the thing! install.sh would delegate to your own CLI

[mbonnin]

The CLI would know how to bootstrap/auto-configure itself

[mbonnin]

install.sh is a very simple script that just needs to detect the current arch, select the appropriate file and run it

[jmfayard]

mmh then you can centralize installing shell completion in clikt
that makes sense

[mbonnin]

Yea, and dealing with zsh vs bash vs fish, unzipping a newer version, checking when a newer version is available in the background, etc.. all of that logic could be in a lib.

[jmfayard]

I like it

[jmfayard]

maybe that could be proposed to the CliKt project?

[mbonnin]

I wonder if there's value in not binding it to Clikt

[jmfayard]

it could be a separate repo reusable by others

[mbonnin]

Yea, I do love CliKt myself but if someone wants to use kotlinx.cli or nothing at all I don't see any reason they couldn't reuse the bootstraping lib

[mbonnin]

Now we just need the hardest part...

[mbonnin]

...a name 😅

[jmfayard]

The only requirement is that it starts with a K no?

[jmfayard]

=> kickstart

[mbonnin]

kickstand 🚲

[Big Chungus]

Native bin should use native distribution platforms, just like js bin uses js distribution platform (npm).

Windows: winget package or msi installer
Linux: rpm, deb or flatpak to cover all distros
Mac: mainly brew

[Big Chungus]

What would be useful here, is some cli tool to package native binary (not necessarily from k/n) into winget, flatpak and tap distributables. Surely there must be something out there already for that (seeing as c app would likely use the same tooling for this)

[jmfayard]

@Big Chungus
but that's way more work for the maker of the CLI tool
last year I tried to make a brew recipe here and had to learn a ton of stuff for it to work https://github.com/jmfayard/kotlin-cli-starter/blob/main/kotlin-cli-starter.rb
and then it got reject because I didn't realize you should make your own tap instead to contribute to homebrew directly

For large CLI tools that's probably the best option
but that would raise significantly the bar of when it's worth the effort to write a CLI tool in Kotlin
you would spend more time on packaging than actually programming

CLI tools in Python/Typescript many other use the package manager of their language instead of the native package installer and that's probably why

[mbonnin]

Also if I'm going to install a cli, I don't want to double click a msi or dmg, I just want to stay in my terminal

[Big Chungus]

That's just the burden of native world

[jmfayard]

Why does it matter if it's native or not?
When I use tldr from the command line, I have no idea if it's interpreted or compiled

[Big Chungus]

Because the whole point of native is that it can run and install on it's own without assuming extra runtimes

[jmfayard]

with a kickstart.sh script that uses curl you can run and install it without assuming extra runtimes

[Big Chungus]

Yes, but you cannot install and update via "native" package managers for the platform

[Big Chungus]

i.e. no auto updates and maintenance

[jmfayard]

that's a good point yes

[jmfayard]

What would be useful here, is some cli tool to package native binary (not necessarily from k/n) into winget, flatpak and tap distributables. Surely there must be something out there already for that (seeing as c app would likely use the same tooling for this)

then I guess the question is whether other language communities comipling to native already have something to distribute executables that we could steal 🙂

[Big Chungus]

If easy distribution is your must-have, stick with higher level runtimes. There's absolutely nothing wrong with that

[Big Chungus]

Flatpak has a lot of helpful docs and tooling for sure

[Big Chungus]

No clue about winget and brew

[jmfayard]

kotlin.js with npm is actually pretty straigthforward

[Big Chungus]

Yep, the benefit of runtime

[jmfayard]

Flatpack + a guide about homebrew tap might do it

[Big Chungus]

Or be a bit cheezy and only publish to homebrew (as it supports linux headless apps too)

[Big Chungus]

Not many folks on linux have linuxbrew installed though

[jmfayard]

it would also probably be helpful to have a homebrew tap for Kotlin CLI apps instead of everyone creating its own tap of one recipe

[Big Chungus]

You mean like a template yml config (not familiar with how homebrew works at all)

[jmfayard]

Homebrew doesn't allow you to self-publish your stuff, so you have to create your own repository. Usually with one recipe. Would be better to have a community one
https://github.com/jmfayard/homebrew-tap

[mbonnin]

I don't know about a community brew tap. It's pretty straightforward to download from a user tap: brew install jmfayard/super-cli

[mbonnin]

What's the value of doing brew install kotlincommunity/super-cli instead?

[mbonnin]

Curation maybe? But that is some work

[jmfayard]

one repository instead of 10 repositories ?
discoverability
helpful docs on how to do it

[mbonnin]

How to do what? Installing the cli?

[mbonnin]

I always go to the project homepage and get the instructions from there

[mbonnin]

Agree on discoverability albeit it comes with a high price (having maintainers to maintain the community repo)

[jmfayard]

how to produce the Ruby recipe for a Kotlin tool specifically instead to read the complete huge doc

[jmfayard]

just trying to lower the barrier to entry

[mbonnin]

Ah yes, that is cool. But that can be a separate repo

[mbonnin]

It's mostly doc

[jmfayard]

totally