<@U0B8ZP13Q> There are several ways to get a scrip...

# scripting

[ilya.chernikov]

@cedric There are several ways to get a scripting engine with customizations (including classpath), depending on your needs. All of them require some coding so far, and there is still almost no documentation, but in fact this is not too difficult. See the thread below for some directions:

[ilya.chernikov]

First you need to create (or find) your “script definition”, which is a definition of your customizations.
If you need dynamic classpath, i.e. the possibility to write something like @DependsOn(...) in your scripts, so the dependencies are fetched from e.g. maven on compilation, then the place to start is kotlin-main-kts - https://github.com/JetBrains/kotlin/tree/1.3.40/libraries/tools/kotlin-main-kts - and in particular this place, if you want to customize yourself - https://github.com/JetBrains/kotlin/blob/1.3.40/libraries/tools/kotlin-main-kts/src/org/jetbrains/kotlin/mainKts/scriptDef.kt#L28

[ilya.chernikov]

(The public kotlin-main-kts jar contains also a stripped down ivy code, so it could be used without external dependencies.)

[cedric]

Thanks @ilya.chernikov, will take a look and get back to you if I have questions

[ilya.chernikov]

That’s not all, please hold on. 🙂

[cedric]

Ok!

[ilya.chernikov]

If you want to add a few static jars that you can detect on the initialization time, then you can drop the refneConfiguration block from the MainKtsScriptDefinition and use the dependenciesFromClassContext function used around the same place.

[ilya.chernikov]

And then you’ll need a scripting host. There are two variants basically:

[ilya.chernikov]

You can create a JSR-223 host (so you can use something like`ScriptEngineManager().getEngineByExtension(“kts”)`). For this, please have a look a the new JSR-223 implementation https://github.com/JetBrains/kotlin/tree/1.3.40/libraries/scripting/jsr223
you will need to basically copy it and replace compilation and evaluation configurations here https://github.com/JetBrains/kotlin/blob/1.3.40/libraries/scripting/jsr223/src/kotlin/script/experimental/jsr223/KotlinJsr223DefaultScriptEngineFactory.kt#L23 with the ones built from your script definition.

[cedric]

1.3.40 uh, so really bleeding edge 🙂

[ilya.chernikov]

Alternatively you can make your own custom host like this - https://github.com/JetBrains/kotlin/blob/1.3.40/libraries/examples/scripting/jvm-simple-script/host/src/org/jetbrains/kotlin/script/examples/jvm/simple/host/host.kt#L18

[ilya.chernikov]

The simple host variant is working for some time already, so you don’t need 1.3.40 for that.

[ilya.chernikov]

That’s basically it, so please. have look and ask back if something is unclear or not working.

[cedric]

@ilya.chernikov Is is possible to specify a current directory before calling engine.eval()?

[ilya.chernikov]

There is no special feature in scripting for the current dir setting, for sure.
What are you trying to achieve?

[cedric]

Well, just evaluate a Kotlin script but from a specific directory, instead of the directory that the host process started in

[cedric]

Like ProcessBuilder allows. Seems like eval() should allow that too.

[DALDEI]

late to the party -- but re: 'current directory', Java has no native concept of 'current directory' that is cleanly supported, intentionally . ( Not all environments that run JVM support a concpet of 'current' directory).
On some platforms you can detect, but not change the effective 'current directory' by resolving "." to an absolute path (you can try looking at "PWD" but thats less likely to be valid).
There is nothing you can do to 'change' the CWD (since it doesnt exsist.
If you could change it -- on most platforms it would be processs wide not thread local.
( such as if you wrote a JNI native that accessed the underlying chdir() on linux).
You can 'fake' it in higher level way by maintainng a thread local "Path Prefix", but this would only work for APIs that were cooperative (aka not File or Path).
xmlsh (www.xmlsh.org) does this to emulate "cd" and "$PWD" on a per thread and per shell basis, but it only 'works' at the abstraction layer provided by the app/script code. Kotlin script is the same as kotlin as JVM for this purpose, so the technique wouldnt work very well.
From this, one can deduce the difference between ProcessBuilder and eval()). PRocessBuilder creates a new process and provides its initial directory (Where OS supports it). differnt then 'current' diretory. eval()) doesnt start a new process -- or if it does its hidden from you

[ilya.chernikov]

@DALDEI Thank you for putting it in a perspective, very useful insights.

[cedric]

The current directory concept I was talking about is a directory stored by the script engine that gets passed to process builders going forward. That's how shells emulate the concept of a current directory.

[ilya.chernikov]

In this case it is not a scripting feature, but simply some property that should be accessible from script. You can have it with bindings or with a property in the script definition.

[cedric]

It’s not just that, it makes sense for example for a script to have a default directory (File("")) that is not stuck to the directory where the JVM launching that script was started. Probably the directory that this script is in.