Please provide an AppImage for Linux

[probonopd]

Currently it is extremely easy to download and run Mu on the Mac, but on Linux the command line is involved, making it more complex than on the Mac.

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter

An AppImage is essentially a self-mounting filesystem (similar to a Mac disk image) that contains Python, PyQt, Python libraries, icons, other resources, and the application.

Complex Python/PyQt applications such as Ultimaker Cura are already being shipped in AppImage format.

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

Here is a simple recipe that can produce an AppImage from pip:
https://github.com/AppImage/AppImages/blob/master/recipes/Mu.yml

On a Debian/Ubuntu based distribution, you can run it with

wget https://raw.githubusercontent.com/AppImage/AppImages/master/pkg2appimage
bash -ex pkg2appimage Mu

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

[ntoll]

Oooh... I didn't know about this. I'll take a look.

A quick question: what testing is available to check the appimage on all supported platforms?

[probonopd]

I am using testappimage along with Live ISOs of various distros.

[abixadamj]

I agree that AppImage would be great solution! I will help with creating this.

[probonopd]

On a Debian/Ubuntu based distribution, please try

wget https://raw.githubusercontent.com/AppImage/AppImages/master/pkg2appimage
bash -ex pkg2appimage Mu

It should produce a working AppImage.

[tim1mw]

+1 for this, I would have much preferred an appimage.

I'm currently wrestling with the pip install which is crashing due to other changes in the latest distros (#875 ) so I can't currently run mu at all.

[tmontes]

All,

Letting you know that I have made substantial progress towards the goal packaging Mu Editor as a Linux AppImage.

Details in this pup issue, in this just merged pup PR, and in this Mu Editor PR.

Once these items are ironed out we should be able to ship our first "official" Mu Editor AppImages -- whether they will work and make our Linux users' lives easier or not is something that we'll have to wait for and see. :)

Stay tuned!

[probonopd]

Cool! Please let me know when there is an AppImage that can be tested.

[tmontes]

All,

First attempt at AppImage Linux packaging for the current release of Mu just automatically built available at the bottom of this page.

Just tested it on Debian 10:

• Download.
• Make executable.
• Run it!

Let me know how it goes, please! :)

[probonopd]

AppImage packaged Mu does not ship with Qt dependencies that something akin to pip install PyQt requires from the underlying system.

It is recommended to privately bundle all libraries that Qt depends on, with the possible exception of those explicitly listed on https://github.com/AppImage/pkg2appimage/blob/master/excludelist. Tools like linuxdeployqt, linuxdeploy-plugin-qt and many spezialized deploypent tools for Python usually do that.

[probonopd]

@tmontes QtPlugin is completely unrelated. That is the FreeBSD side of things. In oder to support Linux AppImages, helloSystem is using a dedicated Debian Runtime.

[carlosperate]

From that AppImage exclude list:

libxcb.so.1
# Workaround for:
# Fedora 23
# symbol lookup error: /lib64/libxcb-dri3.so.0: undefined symbol: xcb_send_fd
# Uncertain if this is required to be bundled for some distributions - if so we need to write a version check script and use LD_PRELOAD to load the system version if it is newer
# Fedora 25:
# undefined symbol: xcb_send_request_with_fds
# https://github.com/AppImage/AppImages/issues/128

Could that be relevant?

[probonopd]

I don't think so but let's not invest too much time into my "unusual" setup for now. Once there is a downloadable AppImage (not inside a zip) I can run it through the automated AppImageHub test.

[carlosperate]

@probonopd there is downloadable AppImage with this URL in case you'd like to run it through the automated test: https://github.com/mu-editor/mu/releases/download/v1.1.1/Mu_Editor-1.1.1-x86_64.AppImage

[abixadamj]

Just for a record. Working fine on Ubuntu 20.04, but I have Mu in local got cloned repo, so I have all neccessary libraries in system.

[carlosperate]

Thanks for testing!
I also tried it on a brand new VM install of 20.04 and it worked well 🎉

[dhalbert]

Tested on Ubuntu 22.04 x64 (arriving next month -- note 22.04, not 20.04).

$ Downloads/Mu_Editor-x86_64.AppImage 
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run. 
You might still be able to extract the contents of this AppImage 
if you run it with the --appimage-extract option. 
See https://github.com/AppImage/AppImageKit/wiki/FUSE 
for more information

22.04 has libfuse3. I installed libfuse2, but no joy:

$ Downloads/Mu_Editor-x86_64.AppImage 
No settings file found at /home/halbert/.local/share/mu/venv.json; skipping
Segmentation fault (core dumped)

[carlosperate]

@tmontes I can confirm that on a fresh install of Ubuntu 22.04 we get that FUSE error message, and after installing libfuse2 there is a seg fault when trying to run the AppImage.

$ ./Mu_Editor-1.1.1-x86_64.AppImage 
No settings file found at /home/carlos/.local/share/mu/venv.json; skipping
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Segmentation fault (core dumped)

[carlosperate]

The seg fault might be an X11 issue, as this seems to work:

$ QT_QPA_PLATFORM=wayland ./Mu_Editor-1.1.1-x86_64.AppImage 

And these segfaults:

$ QT_QPA_PLATFORM=xcb ./Mu_Editor-1.1.1-x86_64.AppImage 
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Segmentation fault (core dumped)

$ env -u WAYLAND_DISPLAY ./Mu_Editor-1.1.1-x86_64.AppImage 
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Segmentation fault (core dumped)

[ntoll]

Experimental AppImage version added to our downloads page. Please let us know how you get on. Thank you!

[tmontes]

All,

We've updated the docs on using the Linux AppImage at https://codewith.mu/en/howto/1.1/install_linux.
Planning to update as others try it out under other Linux distributions.

Your feedback will be welcome. Thanks!

[probonopd]

Thanks for making an AppImage, which almost passes the test, but not quite: AppImage/appimage.github.io#2925

[MMachado05]

Out of curiosity, what was the goal with packaging the AppImage inside an archive tar file? It seems to me that simply providing the AppImage solely and directly from the download button would provide a much quicker setup process.

[carlosperate]

@probonopd do you know how providing the AppImage in a tar file breaks appimaged (and similar things) if the user unpacks the file anyway? I would assume, once the .AppImage file is in the file system everything should work as expected?

The main reason is archived into a tar file is specifically to preserve permissions. This is an application for very novice users, so we cannot assume they know how to configure this kind of thing. Providing instructions on how to change this in every distro/destop environment is extra work and extra maintenenance (and when things change it can be more confusing that useful), and even when we have instructions about setting permissions, we still had users not following the instructions and reporting issues with executing the file (and that's only those that are advance enough, care enough, or know about how to reach us via GitHub, gitter or other methods).

[probonopd]

@carlosperate it is an extra step to unpack the application from the archive, which (depending on the size of the application) can take additional time. Once the AppImage is unpacked, it works properly with appimaged of course. But you have this extra step rather than it being automatic.

[carlosperate]

Thanks for the quick response @probonopd!

In my own personal opinion, I think the extra step is worth it. In all Linux systems I've tested, unpacking a tar file can be done via double clicking on the icon (with or without a GUI window with additional options), and the majority of users would be familiar with that operation already.
It might be a bit annoying having to wait for the extra step to unpack the tar file, but it's not even compressed, so hopefully it's not that bad, and it's a one-time-only step.

I would completely agree that for other applications, targetting more experience users, it can make sense to delivery the .AppImage file directly, and those users might be able to easily make the file executable. But one of the goals of Mu is to enable very novice users, on their first coding steps, who might not know much about how Linux/OSes (or even computers) work, and who more-often-than-not do not read instructions/documentation. So in those cases, friction at the beggining of their journey can impact quite negatively their motivation, and being able to double click on the .tar file + double click on the .AppImage file directly, that can make a huge difference.

[probonopd]

@carlosperate I see. Maybe it'd be a compomise to provide both an archived an an unarchived download?

[carlosperate]

Yes, I think that should be fine.
We upload the installers to each GitHub Release, and then link to them from the website. We could link to the archive file from the https://codewith.mu download page, and still have the .AppImage available in the GitHub release, so other people can download it from there. And I guess if we were to add it to the AppImage catalog, that would link to the direct file as well.