Hello, I'm from <https://github.com/Kotlin/KEEP/is...

# scripting

[WayZer]

Hello, I'm from https://github.com/Kotlin/KEEP/issues/75#issuecomment-1595972361. First, sorry for asking in the wrong place.

first, you probably need to implement your own variant (or two) of the @Import annotation with appropriate handling, so you don't need to hack around the existing Import from .main.kts and isStandalone flag.

I have implement runtime, using custom annotations.

Second - there are still missing pieces in the IDE support, namely imported scripts, but we can discuss, what to do with it, e.g. over slack.

Yeah, I want to know how to implement IDE support, mentioned in above comment.

[ilya.chernikov]

Hello!
I'm not sure it is conceptually easy to implement what I assume you want.

Since you want to split your script into several parts, it seems that the importScripts configuration property, which is set by the @Import annotation in the main .kts, is the right mechanism to use. But there are two problem with it: first that IDE support is not done yet, and the second is that importing .kt files is quite controversial feature and might be removed at some point. But if you can switch to .kts imports and live with some workarounds on the IDE side, until the support is implemented on our side, this would be the best variant.

On the other hand, it may look like you already have a kind of a project with the script and .kt files around. If this is the case, it might be better to implement you own host compilation schema, compiling all files in a directory as a single project, and then find and run the compiled script. In this case for the IDE support it will be enough to use isStandalone(false).

You seems to be trying some mix of this approaches, which requires a new scripts compilation schema, which is not supported, at least not yet.

So I would suggest you to think whether a "standard" compilation schema would work for you, and maybe try to stick to it.

As of the IDE support for importScripts, maybe @Andrei Klunnyi can give some more info.

[WayZer]

I'm using the second approach for already 2 years. That works fine except classpath pollution (one class will see many class not exist in runtime, as in runtime modules are isolated).

So I want to move to the first approach. I know import .kt is controversial, but importing .kts can't meet needs(causes cycling reference in constructor). Maybe this is not a common application scenario(LivePlugin also want this for multifile supporting), so I would implement IDE supporting myself.

In my assumption, a .kts stands for a module, a .kt only belongs to one .kts . So I want to create IDEA modules for this, one .kts create a module. But package and module root prevent my implementataion. As many .kts shares the some directory(one kts one directory seems ugly), especially with nested package directories(use as namespace to prevent classname conflict, for example core.Module and ktor.Module)

I have summed up three general point:
• importSources with IDE support, let .kts and .kt in the same module(classpath) to compile. importSources don't affect implicitReceivers and this replace the usecase for importScripts but .kt.
• packageName , compile .kts without explicit package specified package. (package conflict may be the duty of host, not the script).
• module mechanism design for `.kts`(resolve cycling reference for ``importScripts`` with .kts), like module mechanism in javascript or python, this may require further research. And not sure whether this is the scripting application scenario.
It seems current scripting more like single file tool(kscript or main.kts) or configuration(ktor routing or space.kts). Without multifile module mechanism and cycling reference support, it may be hard to apply to larger application.

[ilya.chernikov]

I can understand your points, but at the moment we cannot offer an extension of scripting in that direction, because it will require some noticeable design and implementation work, and we don't see much demand for it. Maybe yours is the only one that is clearly expressed. And taking into account that our resources are limited, we'd rather spend it on something that users demand.
If you think that it is an important use case, and we should develop the scripting into this direction, you probably need to prototype some approximation to the tool you need yourself, and then attract some users to it, so the usefulness of the tool will become obvious. The original kscript is a good example of this - it demonstrated the demand of certain approaches to scripting, and we backed some of them into the Kotlin scripting support.

[WayZer]

I can understand your resources are limited.
• importSources with IDE support has universal demand. And can replace the usecase for importScripts non-kts file.
◦ The main.kts has @file:Import , but no IDE support.
◦ The live-plugin , has a longtime issue for this(https://github.com/dkandalov/live-plugin/issues/105)
• packageName this is simple option. If you don't have time to implement it, I think bytecode relocation is OK.
• module mechanism is a large project, and seems too complex for Kotlin scripting.
In general, importSources is the most needed of three point. If you don't have time to work on it, would you provide some tips for me to write IDEA plugin for implement this IDE support?

[WayZer]

Another way for point three, Is it possible to compile kts like object class?