Follow up question: if the standard/most common wa...

# scripting

[josephivie]

Follow up question: if the standard/most common way of running .kts files will be with this script runner, why is it not default? The complexity of use is keeping scripting from becoming widely useful. I'd like the equivalent python script.py, and I'd like it to be part of installing Kotlin. Until it's that simple, I can't rely on distributing .kts files to others as a consistent, portable, easy way of giving other people scripts.
I know kscript exists, but it only supports *nix.

[gildor]

Do you mean to have:

kotlin script.kts

instead of existing

kotlinc -script script.kts

[gildor]

or are you talking about dependencies support?
Because as I understand python also doesn’t support remote dependencies

[josephivie]

I mean to have
kotlinc -script script.kts (or even simpler)
instead of
kotlinc -cp some-jar-i-downloaded-separately.jar -script sample.main.kts

[josephivie]

Correct, but python also has the ability to install dependencies globally so accessing some dependencies is not as much of an issue. I'd greatly prefer using Maven annotations though.

[gildor]

kotlinc -script script.kts already worsk

[gildor]

install dependencies globally

Looks as a bad solution for me
Every time when I work with python global dependencies it was a mess

[josephivie]

That's why I said I'd prefer Maven annotations.

[gildor]

maven annotations are experimental now, so I believe eventually they will be enabled by default

[josephivie]

But without any libraries, scripting is effectively useless

[gildor]

yes

[josephivie]

That's what I'm saying. I need those annotations to be default.

[gildor]

they are not by default for now

[josephivie]

If that's the plan, then awesome. I'll be patient.

[gildor]

not so much to do

[gildor]

I don’t have insides, but I would expect that it would be supported by default at some point

[gildor]

now it’s more like proof of concept

[gildor]

be free to comment, add your usecases on scripting-support KEEP

[gildor]

In general I’m absolutely agree with you, don’t think that I think that current solution is convinient

[gildor]

I would like to have much more powerful scripting out of the box

[gildor]

but also keep in mind that there are many multiple use cases for scripting

[gildor]

for example now I mostly use Kotlin scratch files from IDEA, it’s much more convinient. Yes, it requires project with dependencies, but it’s already cover 90% of my automatization scripting cases.

But it doesn’t work if you want to distribute script. So in this cases I just use Kotlin application, it also provides nice additions, like much better tooling, testing and distribution support

[josephivie]

Yes, and actually, counter-intuitively, I'd argue that makes it worse. If we can never depend on a .kts file to be runnable with kotlinc -script something.kts, the definition of .kts is vague, and it will always be irritating to figure out how to run that script. Maybe we need another file extension to denote that its runnable normally?

[gildor]

definition of .kts is vague

Why so?

[gildor]

it’s runnable normally, not sure what you mean

[gildor]

I believe kotlin something.kts also will be supported on some point

[josephivie]

Because you don't know how to run a .kts without additional context.
A .sh is simple - it is run with shell. There's no questions about it.
If a .kts might require a certain scripting module in order to run, then information about how it works is incomplete without some extra documentation. On the other hand, if .kts files were always run with the same runner, we wouldn't have to wonder.
Perhaps we need a .skt (standalone kotlin) extension to indicate that it will work with just the standard script runner.

[gildor]

A .sh is simple - it is run with shell.

It’s just a convention, you also have to use very particular command to run it

[josephivie]

Exactly. We need a convention that makes it clear what is a normal kotlin script file and what requires some additional magic, like a .gradle.kts

[gildor]

.gradle.kts is completely different story

[gildor]

You don’t need any magic to run .kts

[gildor]

.gradle.kts uses Kotlin scripting to implement scripting language for Gradle and provides a lot of own features, default imports, dependencies on top of it

[gildor]

.kts can be run by kotlinc -script, no magic

[gildor]

if you need dependencies it’s another story and I hope (and think it will happen) will be supported out of the box

[josephivie]

Ah, OK. We're thinking along the same lines, then. I'd like that to be the convention, where anything that uses special embedded scripting features has a different extension. I'd like the extension to communicate clearly how it is run.

[josephivie]

I just don't like that the way kotlinc is set up right now encourages special custom runners. That's something that can be left to people using the library from Maven directly.

[gildor]

special embedded scripting

Not only embbedded! That’s the whole point. .something.kts is convention that allows to implement own script definition

[gildor]

if someone in classpath registered script definition for this extension

[josephivie]

Right, and as long as everyone always adds the .something before the .kts, I'm cool.

[gildor]

and kotlin-main-kts is just an example that uses public scripting API, very powerful API for me

[josephivie]

Yep, and that's pretty nifty. I think I might write a quick installer script that makes an alias so that you can just use kotlin something.kts right now.

[gildor]

everyone always adds the .something

addition extension means that user of this script should somehow get script definition for it, this is what happening in kotlinc -cp kotlin-main-kts-1.3.41.jar

So I see 2 parts of this story:
1. Support of dependencies. I see .main.kts just as temporary solution/proof of concept. Essentially everyone want dependencies in their scripts, it should be supported at least with special key for kotlinc
2. Discoverability for custom script definition. if you want to provide own kinds of scripting and call it josepth.kts, you can distribute this script and script definition, but how user can run it. It’s not so simple question.
Current solution, you just download script definition jar and add it to classpath (-cp key for kotlinc or even just add to yor jre\lib\ext directory, which is essentially become global dependency, nasty but works)

I would like to have improved discoverability for this, like script author can specify ScriptDefinition dependency using some default annotation, or even install them globally.
This is why I recommend you, if you interested in this feature, comment scripting KEEP. At least with your use case

[josephivie]

That's correct. Sorry I'm not doing too well at communicating.
I was worried that by making people specify (for now) that KTS files with dependencies must use the kotlin-main-kts jar, that it would become standard to always use some kind of special script definition jar, which would muddy what a .kts was - with no useful default, there would be no useful meaning to having a .kts extension at all. Distributing them would be a nightmare, as everyone has to install custom script definitions for most scripts.
For point 2, it might be good if there was a general registry mapping `.something.kts`extensions to their definitions.

[gildor]

what kind registry? Who will control it? How register your own extension.
I think it’s just too complicated, we already have Maven, which works perfectly as registry
And script author just should specify script definition dependency

[josephivie]

I was just thinking something on the Kotlin website, not necessarily programmatic. Heck, even a wiki page. Just a place to go to find information on it.

[gildor]

I know 0 public script definition except kotlin-main-kts, which is again, looks more like proof of concept itself

[josephivie]

I do like the idea that all .kts files should just include an annotation specifying the Maven repository of the script definition, if that's what you mean.

[josephivie]

I'm imagining that Gradle might have one eventually, as would Kobalt.

[gildor]

Nope! not ” all .kts files”, but only ones who really want to use some Script Definition features

[gildor]

Gradle doesn’t require any registrly, gradle.kts script definition provided by Gradle classpath, you cannot run it without Gradle, which makes a lot of sense, it’s just different use case. Scripting language for another existing application, they are not standalone

[ilya.chernikov]

Thank you for the nice discussion, guys.
In general there are quite many unsolved design issues on a way to make the standard kotlin “command-line scripting” good enough to challenge established approaches, like python. Therefore we are now concentrating on providing a good API for scripting in all custom cases.
And in many cases specialized solutions will do a better job in providing kotlin scripting functionality to the end user - see e.g. at kash and kscript, and maybe we just need to provide all the APIs and internals to make it easy to create such shells.
But it is clear that there is a demand for the standard out-of-box scripting, so we’re thinking about it, but how it will be approached is not yet clear.
The kotlin-main-kts is an experiment to provide a prototype of a standard scripting, and it seems that it is a baseline of what people are expecting. So maybe it will become part of the standard scripting eventually.

[cedric]

For what it's worth, when you run Kash, all scripts ending in kash.kts are run as native commands, e.g. a.kash.kts can be invoked with just a (you just need to tell Kash where to find your scripts). Also, remote dependencies in script files are supported, so you can use Maven coordinates directly inside your scripts