AppImage

[mtoohey31]

Closes #1073.

Depends on #283.

So far this PR only contains a simple script for generating the AppImage, based on neovim's genappimage script. Since AppImages seem to require a desktop file and a logo file, #283 needs to be handled first. Also, as pickfire mentioned here, once we've added the desktop file we'll need to let package maintainers know.

Questions

• I've made sure that the runtime folder is being detected (tree-sitter grammars work properly), is there anything else that might be problematic with this packaging format that I should check?
• How should we work this into the release process? Should I add the commands in the script as a step in the publish job of the release.yml action file, or is there somewhere else I should put them?

TODO

• /lib64/ld-linux-x86-64.so.2 seems to be hardcoded into the hx binary in the resulting AppImage. Like I mentioned in Flatpak package #2076 I'm new to AppImage so I'm not sure if this is incorrect, but it might be. This site seems to indicate that /lib64/ld-linux-x86-64.so.2 is required for AppImages anyways, so I believe this is fine.

[the-mikedavis]

I've made sure that the runtime folder is being detected (tree-sitter grammars work properly), is there anything else that might be problematic with this packaging format that I should check?

The setup of the HELIX_RUNTIME var looks good, I don't think there should be any other pitfalls 👍

How should we work this into the release process? Should I add the commands in the script as a step in the publish job of the release.yml action file, or is there somewhere else I should put them?

Yep, that sounds perfect 👍

[mtoohey31]

Ok, after the latest few commits I believe everything is ready to go. The workflow runs as expected (see the logs here), and updates with appimageupdatetool also work. With the current master, the size of the AppImage is 12.5 MB, which is a bit larger than the releases for linux and macos (which makes sense because more things will be bundled into the binary), but it's still smaller than the windows release.

Is it ok to merge this with the placeholder logo then update it once we've settled on an official logo, or do we want to decide on a logo before merging?

[the-mikedavis]

I'm ok with the purple dot icon for now - it seems like a good simple placeholder. What do others think?

[archseer]

This should build a separate archive. I don't want to bundle it together with the binaries because it will bloat the archive size for users that don't want the AppImage.

[archseer]

Might make sense to do this as a separate workflow altogether?

[mtoohey31]

Do you mean the workflow artifacts, or the release assets? I'm pretty sure none of the other release assets contain the AppImage, just the AppImage itself (see my test release here vs the sizes of the latest official release), though the AppImage does get bundled into the linux release workflow artifacts if that's a problem.

[archseer]

though the AppImage does get bundled into the linux release artifacts if that's a problem.

Yes, that's what I meant. Various distributions simply repackage the linux release, bundling AppImage into the same archive will increase the download size. The AppImage is a separate package/distribution format and it should be packaged into it's own archive.

[mtoohey31]

Ah shoot, I meant to say workflow artifacts. Just to make sure we're on the same page, the AppImage gets bundled into the linux artifacts saved here in the workflow run, but not here on the release page. Are distributions using the workflow artifacts instead of the release artifacts?

[the-mikedavis]

Oh I see. I think this is currently fine: the AppImage is built in the build step for the x86_64 linux image and it also ends up in the workflow artifacts but then it ends up as a separate release artifact. (see here)

[the-mikedavis]

Based on the runs in your fork this looks good 👍

Thanks for working on this!

[archseer]

Thanks!