I have a standalone amper project which also conta...

# amper

[JG]

I have a standalone amper project which also contains a bunch of files with their own main functions. When I load the project in IntelliJ, I was able to execute these individual main functions.
However, on the latest Intellij EAP/Beta (not sure when exactly this broke), Intellij shows a run icon beside the main function in these individual files but clicking on that does absolutely nothing.
Similarly I see the run button at the top toolbar with the filename, however run button does nothing and the kotlin icon beside the file name is kinda dim/greyed out as well.
(I am still able to run individual files in Fleet but Fleet has way too many issues to be usable unfortunately.)
Is this intellij issue known and is there a workaround?

[JG]

So far, I have -
• tried the invalidate option in the IDE
• turned on/off K2 mode
• delete all the run configurations
but nothing worked

[JG]

Found the issue. In the run configuration, it is considering the module as <package_name>.common for some reason and changing it to ``<package_name>.jvm` makes the Run button work (although the Kotlin icon is still greyed out).

[joffrey]

Technically at the moment Amper only supports one main class per module (either explicitly specified in module.yaml or automatically discovered by looking at files named main.kt).

The fact that multiple ones worked before in IDEA was rather a happy accident. Now IDEA delegates the execution to Amper, which therefore can only run your "main" main function.

[joffrey]

The presence of a non-working play button in the gutter is a bug, though. There should be no run button for main functions that are not technically the one recognized by Amper

[joffrey]

If you need multiple entry points you can extract those main classes to separate jvm/app modules

[JG]

the "main" main function also does not seem to work though. the only thing which works is selecting the run configuration with the amper icon.

[JG]

(and this project is basically a replacement for the barely supported kotlin scripts, so it has tens of files, each one with a main function and amper is used just for managing dependencies)

[JG]

If you need multiple entry points you can extract those main classes to separate jvm/app modules

you should really see how Rust (Cargo) does multi-executables. in the same config file you can define as many entry points as possible as opposed to amper requiring to split the yaml file and the whole project. really sad 😞

[JG]

https://stackoverflow.com/a/36604610

https://doc.rust-lang.org/cargo/reference/cargo-targets.html#binaries

[JG]

amper is massive improvement over gradle but far behind cargo in terms of intuitiveness and ease of use

[JG]

hopefully it improves further and does not follow the tradition of jvm tooling/(and pretty much everything else) feeling alien to the whole outside world

[joffrey]

but far behind cargo in terms of intuitiveness and ease of use

If you have specific UX issues or improvements suggestions, I'd be really happy to hear them. We're trying to be user-oriented and use-case oriented in the design, and it is super helpful to get direct feedback with real-life cases

[joffrey]

this project is basically a replacement for the barely supported kotlin scripts, so it has tens of files, each one with a main function and amper is used just for managing dependencies

you should really see how Rust (Cargo) does multi-executables. in the same config file you can define as many entry points as possible as opposed to amper requiring to split the yaml file and the whole project. really sad

Could you please describe your use case for multiple entry points? How exactly are you planning to use them? Do you intend to create actual binaries, or just run from the IDE?

[JG]

Well, in Rust a very common way of writing code is to compose everything as a library and then having a separate binary code file defined. This allows publishing the crate as a library for everybody to use while also having possible binaries there. It allows easy way to define multiple binaries e.g. if you did not want an executable with lots of arguments, so you split it up. Similarly, rust allows defining examples in the package which are defined pretty similarly to the multi-binary configuration.

If the code base grows very large, then it also supports splitting the package into separate crates using something called a workspace.

What amper supports is exclusively workspace model but it does not support the programming in the small usecase, where the workspace model is just unnecessary burden.

[JG]

One example at work (not kotlin) is that we have a very big library package and then we import it in another package where we have multiple smaller binaries (clis/daemons) defined in a kind of mono-repo fashion except that it is a single package and makes it much more simpler.

[JG]

Another common use case from work (not kotlin) is that we have a main use case and several smaller (occassional/rare) use-cases and we don't want separate packages for them because it adds maintenance overhead for things which will be rarely used.

[JG]

Again most of my use cases are geared towards CLIs/Daemons which is what I mostly work on. These may not be common use cases for Kotlin as it is mostly geared for mobile apps and backend but still...

[JG]

And the user experience of JVM tooling is very very far from rust / go because of the same reason that JVM tooling is primarily geared for programming in the large usecases which a lot of people like me don't have a need for whereas rust / go tooling is developed by people who work significantly more in the cli kind of use cases etc., so they made those use cases simpler as well.

[joffrey]

Sorry for the delay! Thank you very much for the details. That is quite useful.

I believe the recurring theme in what you wrote is the "unnecessary burden" / "maintenance overhead" of having one module per entry point. You also wrote "a single package makes it much simpler". I'm trying to understand what exactly constitutes this burden. Some things can be made easier than what people are used to, especially Gradle users. For example:
• the creation of new modules could be made very easy: select the second main() function > extract to new module (this feature doesn't exist yet, but is a very real possibility for Amper)
• running different entrypoints from the IDE could be made very smooth with run config2 buttons in strategic places
• the file hierarchy in itself might be considered visual clutter, especially with the src/main/kotlin convention from Gradle. In Amper, it's much shallower (just <moduleDir>/src/main.kt). There is still some inherent inconvenience here, albeit smaller.
Understanding what you mean by the maintenance burden (with your real life cases) would help a great deal here.

Aside from these pain points, what really interests me is how you run these different binaries from your project. Do you run them from the IDE or from the CLI? Do you use them to perform local tasks only, or do you distribute these as applications to other users? In the latter case, do you package/publish one binary with several commands, or one downloadable package with multiple binaries inside, or multiple independent packages that users can download separately?

[abarsov]

However, on the latest Intellij EAP/Beta (not sure when exactly this broke), Intellij shows a run icon beside the main function in these individual files but clicking on that does absolutely nothing.

The presence of a non-working play button in the gutter is a bug, though. There should be no run button for main functions that are not technically the one recognized by Amper

This issue is fixed in release branch, the fix will be available in 2025.1.1 (not sure about 2025.1)