ensoup broken due to 2024.5.1.rc3

[JaroslavTulach]

The latest stable version of ensoup is broken, @radeusgd. To reproduce:

$ wget https://github.com/enso-org/enso/releases/download/2024.4.2/enso-launcher-2024.4.2-linux-amd64.tar.gz
$ tar fxvz enso-launcher-2024.4.2-linux-amd64.tar.gz
$ ./enso/bin/ensoup install engine
$ ./enso/bin/ensoup run Dec01
Error: Could not find or load main class org.enso.EngineRunnerBootLoader in module org.enso.runtime

technically this problem is caused by incompatibility introduced by

• engine-runner and language-server are separate JPMS modules #10823

which has changed the runner entrypoint.

However the biggest problem is that ensoup 2024.4.2 downloads 2024.5.1-rc3

$ ./enso/bin/ensoup list
Enso 2024.5.1-rc3 -> GraalVM 24.0.0-java21.0.2

Either there has to be a way to

• "tell" ensoup (even already released one like 2024.4.2) it is no longer compatible with some future release
• or ensoup shouldn't be adventurous and download unknown latest version (given current state of (in)compatibility of Enso development)
• ensoup only download stable releases - why does it download 2024.5.1-rc3 at all?
• keep the interface between ensoup and enso stable - e.g. don't change the main class

I discovered this problem while investigating use of ensoup inside of Enso VSCode Extension to download Enso engine for users that have a Enso file or project, but don't have anything to invoke it.

[4e6]

$ ./enso/bin/ensoup run Dec01
Error: Could not find or load main class org.enso.EngineRunnerBootLoader in module org.enso.runtime

I guess, to stabilize things ensoup run should rely on calling the enso executable and not trying to invoke Java directly

[radeusgd]

$ ./enso/bin/ensoup run Dec01
Error: Could not find or load main class org.enso.EngineRunnerBootLoader in module org.enso.runtime

I guess, to stabilize things ensoup run should rely on calling the enso executable and not trying to invoke Java directly

The enso executable uses whatever Java is on the Path. One of the main purposes of ensoup was managing JVM installations tied to Enso, so that Enso is run on the right JVM for each version. The idea behind ensoup was that the user may not need to install Java on their system - ensoup will handle that for the user. Leaving that out and running enso binary directly kind of misses the point.

Well we could set JAVA_HOME to the selected JVM and then run the enso executable. But that would be an even more breaking change to ensoup.

ensoup has facilities for saying that a newer engine version requires a newer version of launch logic due to updates. The problem is that these facilities were not used when the breaking change happened in #10823. I'm sorry I missed that in review - I could have seen it before going on vacation, but it wasn't yet ready back then - and then the change was merged when I was away so I didn't get a chance to catch it.

I'm also worried that the change was actually done in such a way that newer ensoup cannot run old engine versions either. I will see if I can amend this and keep the incompatibility window only between a few versions.

[JaroslavTulach]

$ ./enso/bin/ensoup run Dec01
Error: Could not find or load main class org.enso.EngineRunnerBootLoader in module org.enso.runtime

I guess, to stabilize things ensoup run should rely on calling the enso executable and not trying to invoke Java directly

• there is Launching Enso programs instantly #10121 and while implementing it, we will have to make sure ensoup invokes the enso executable

The enso executable uses whatever Java is on the Path. One of the main purposes of ensoup was managing JVM installations tied to Enso, so that Enso is run on the right JVM for each version.

There are changes related to #10121:

• enso is going to be a native image executable
• enso supports new --jvm flag since Support for --jvm option in Enso runner #10374
• enso tries to pick the right JVM (when the --jvm flag without any argument is used) since --jvm tries to find Java executable system-wide. #11500

The idea behind ensoup was that the user may not need to install Java on their system - ensoup will handle that for the user. Leaving that out and running enso binary directly kind of misses the point.

Not if the enso executable is real executable - e.g. once ideas in #10121 are implemented. Once that done users will be able to invoke enso without having JVM installed.

Well we could set JAVA_HOME to the selected JVM and then run the enso executable. But that would be an even more breaking change to ensoup.

I am not sure what exactly would it be breaking? Anyway, the direction for the future is clear: ensoup has to invoke enso executable - note taken - otherwise we will not be able to make enso a native executable.

[radeusgd]

Anyway, the direction for the future is clear: ensoup has to invoke enso executable - note taken - otherwise we will not be able to make enso a native executable.

Ok, I see. With all the arguments above, I'm convinced to change the execution scheme. Let's just ensure we do it in a compatible way this time.