Allow passing custom classpath vars?

Hi! I really am enjoying using kscript. However, one thing that I think is impossible at the moment is being able to pass a custom classpath. Running vanilla kotlinc allows this (obviously, as kscript ultimately pipes through to kotlinc after some other work), and so does the new jshell in Java 9. It’s useful to be able to add a local JAR to the classpath (both when quickly prototyping when you don’t want to deploy a JAR to a Maven repo, and maybe when you’re using kscript on some work project where your JAR isn’t published to a public repo).

In an ideal world, I’d be able to pass both a custom classpath and //DEPS and have them merged into one big classpath. ex: kscript --interactive "//DEPS com.googlecode.libphonenumber:libphonenumber:8.9.6" --classpath="path/to/my.jar", or similar.

Let me know if you think this is a welcome feature. I’d be happy to discuss possible other formats for the classpath arg as well (maybe it could be part of the // directives, so "//DEPS [gradle deps] //CLASSPATH [local deps]"). I would be happy to contribute a pull request as well if there’s interest.

Thanks for reading!

[holgerbrandl]

With respect to the topic of this ticket, the question for me would be if we want to reuse DependsOn or introduce another annotation to allow for local non-maven dependencies? Clearly, this should be in sync with kotlin-scripting.

@ligee How are/would be local jar dependencies supported in kotlin-scripting?

[holgerbrandl]

Indeed @zhuker, it’s not as easy as I thought. The correct workaround is

//KOTLIN_OPTS -cp build/libs/jartester-1.0-SNAPSHOT.jar
//COMPILER_OPTS  -cp build/libs/jartester-1.0-SNAPSHOT.jar

Same with annotation config. See referenced commit for a regression test which I have added to prepare for a more solid support of local jars in DependsOn or a via a dedicated separate annotation.

The reason for the double declaration in the workaround is that the kotlinops are not passed to the compiler, and vice versa. I still think that this is the correct approach here because compiler and runtime options are typically different.