Reducing amount of assets in our releases

[Akirathan]

Let's investigate the amount of assets for every release. A link to a recent release is https://github.com/enso-org/enso/releases/tag/untagged-aed0b8c4d7d0b238bf33

For every platform, we have 6 assets:

• AppImage (or .exe, or .dmg)
• enso-engine
• enso-bundle
• enso-launcher
• enso-project-manager
• project-manager-bundle

AppImage (exe or dmg) [1 GB]

This is our main asset. We need to keep it and maintain it.

enso-engine [630 MB]

enso-engine contains bin/enso executable that is an engine runner. It is also bundled with libraries. We want to have this asset

enso-bundle [900 MB]

$ tree -a -L 3 enso-bundle -I THIRD-PARTY
enso-bundle
├── bin
│   └── ensoup
├── dist
│   └── 2025.1.1-nightly.2025.2.18
│       ├── bin
│       ├── component
│       ├── editions
│       ├── lib
│       └── manifest.yaml
├── .enso.portable
├── README.md
└── runtime
    └── graalvm-ce-java21.0.2-24.0.0
        ├── bin
        ├── conf
        ├── include
        ├── jmods
        ├── legal
        ├── lib
        ├── LICENSE_NATIVEIMAGE.txt -> lib/svm/LICENSE_NATIVEIMAGE.txt
        └── release

16 directories, 6 files

where the dist/2025.1.1-nightly.2025.2.18 directory contains the exact same contents as enso-engine asset.

enso-launcher [20 MB]

$ tree -a -L 3 enso-launcher -I THIRD-PARTY
enso-launcher
├── bin
│   └── ensoup
├── dist
├── .enso.portable
├── README.md
└── runtime

4 directories, 3 files

where dist and runtime are empty.

enso-project-manager [30 MB]

$ tree -a -L 3 enso-project-manager -I THIRD-PARTY
enso-project-manager
└── bin
    └── project-manager

i.e., enso-project-manager contains only project-manager executable.

project-manager-bundle [900 MB]

$ tree -a -L 3 project-manager-bundle -I THIRD-PARTY
project-manager-bundle
├── bin
│   └── project-manager
├── dist
│   └── 2025.1.1-nightly.2025.2.18
│       ├── bin
│       ├── component
│       ├── editions
│       ├── lib
│       └── manifest.yaml
├── .enso.bundle
└── runtime
    └── graalvm-ce-java21.0.2-24.0.0
        ├── bin
        ├── conf
        ├── include
        ├── jmods
        ├── legal
        ├── lib
        ├── LICENSE_NATIVEIMAGE.txt -> lib/svm/LICENSE_NATIVEIMAGE.txt
        └── release

16 directories, 5 files

[Akirathan]

I have couple of questions

1. enso-project-manager asset contains only project-manager executable. It seems useless. Right? As it cannot work - it should not be able to open any project
2. What is the purpose of project-manager-bundle ? That seems unnecessary if we already have enso-bundle
3. Can we get rid of enso-bundle as well? It should be enough to have just enso-launcher and install whatever you need with it.

[Akirathan]

TL;DR We have 6 assets for every platform in every release. enso-project-manager asset is completely useless. Both enso-bundle and project-manager-bundle seem useless as well. My suggestion is: Can we keep only AppImage, enso-engine and enso-launcher?

[radeusgd]

enso-bundle was meant as a thing that you can download to start using CLI Enso right away. I think we can indeed remove it - the main entry point for users is the GUI bundle, and for CLI it should be enough to download the lightweight launcher and get it to install the latest release upon first run.

[4e6]

I agree that we need to cleanup the release artifacts. I'd leave just IDE executables and corresponding sha256 hashsums. The rest are not tested and should not be visible to the users IMO. I'd move other artifacts to the actions release page (https://github.com/enso-org/enso/actions/runs/13381982489) so that they can be available for developers

[Akirathan]

That is a very good point. That way, only the AppImage, exe and dmg assets will be public, and the rest of the assets will be "private" - attached as artifacts on GH action.

[radeusgd]

I think it may make sense to keep the enso launcher still, as it is the CLI version of Enso in case someone wants it.

[Akirathan]

I thought that the "official CLI version of Enso" is enso-engine nowadays? It is definitely more straightforward to run an Enso program via enso-engine than via launcher that needs to download something in the first place.

[jdunkerley]

I believe the launcher should be included as that is the suggested way to use CLI for end user as I understand it.

We certainly fixed it up fairly recently to be working again.

[JaroslavTulach]

I'd leave just IDE executables and corresponding sha256 hashsums. The rest are not tested and should not be visible to the users...

Enso is a dual nature system. We need artifacts that support its usage from CLI. If those artifacts aren't tested (and testing in needed) we need to test them.

[JaroslavTulach]

enso-launcher [20 MB]

$ tree -a -L 3 enso-launcher -I THIRD-PARTY
enso-launcher
├── bin
│   └── ensoup
├── dist
├── .enso.portable
├── README.md
└── runtime

4 directories, 3 files

where dist and runtime are empty.

• launcher is being used
• launcher downloads other artifacts
• we need to continue releasing them

[JaroslavTulach]

enso-launcher [20 MB]

$ tree -a -L 3 enso-launcher -I THIRD-PARTY
enso-launcher
├── bin
│   └── ensoup
├── dist
├── .enso.portable
├── README.md
└── runtime

4 directories, 3 files

where dist and runtime are empty.

• I'd suggest to rename enso-launcher to ensoup.
• I am not however sure about the consequences...
• Consequences might not be that bad, no other part of the system shall reference ensoup
• at most we need to update documentation to reference this artifact as enso updater

[JaroslavTulach]

A link to a recent release is https://github.com/enso-org/enso/releases/tag/untagged-aed0b8c4d7d0b238bf33

enso-engine [630 MB]

enso-engine contains bin/enso executable that is an engine runner. It is also bundled with libraries. We want to have this asset

enso-bundle [900 MB]

Please note that the download section for Enso Engine links to the enso-bundle, not enso-engine!

• that's the reason why Native enso bundle contains GraalVM, but --jvm cannot find it #12302 talks about enso-bundle

[JaroslavTulach]

enso-project-manager [30 MB]

$ tree -a -L 3 enso-project-manager -I THIRD-PARTY
enso-project-manager
└── bin
    └── project-manager

i.e., enso-project-manager contains only project-manager executable.

project-manager-bundle [900 MB]

$ tree -a -L 3 project-manager-bundle -I THIRD-PARTY
project-manager-bundle
├── bin
│   └── project-manager
├── dist
│   └── 2025.1.1-nightly.2025.2.18
│       ├── bin
│       ├── component
│       ├── editions
│       ├── lib
│       └── manifest.yaml
├── .enso.bundle
└── runtime
    └── graalvm-ce-java21.0.2-24.0.0
        ├── bin
        ├── conf
        ├── include
        ├── jmods
        ├── legal
        ├── lib
        ├── LICENSE_NATIVEIMAGE.txt -> lib/svm/LICENSE_NATIVEIMAGE.txt
        └── release

16 directories, 5 files

Yes, enso-project-manager and project-manager-bundle seem pretty useless:

• project-manager is only used by the IDE
• nobody shall be using it standalone
• at least I can't imagine why would anyone want to do that?

[JaroslavTulach]

enso-engine [630 MB]

enso-engine contains bin/enso executable that is an engine runner. It is also bundled with libraries. We want to have this asset

enso-bundle [900 MB]

The enso-engine seems to be missing GraalVM. As such it is crippled as it doesn't support execution with --jvm:

enso-2025.1.1-nightly.2025.2.18$ ./bin/enso --jvm
[WARN] [org.enso.runtimeversionmanager.components.GraalVersionManager] Runtime search path `~/.local/share/enso/runtime` is not a directory
[WARN][org.enso.runner.JavaFinder] No appropriate JDK found in the distribution runtimes. Trying system-wide JDK.
[WARN][org.enso.runner.JavaFinder] No JDK found in JAVA_HOME. Trying java on PATH.
[WARN][org.enso.runner.JavaFinder] No JDK found on PATH. Cannot start the runtime.
Cannot find java executable

At current state it cannot be considered a full featured CLI distribution of Enso.