AppImage

[izzylaif]

Could you also release official AppImage, since you already do flatpaks?
AppImage seems to be superior in so many ways, including portability.

[paolostivanin]

Hi, it depends on how much this is gonna require for creating and maintaining it. Will look into it though.

Thanks :)

[izzylaif]

Great news. The creator and main maintainer of appimage format - probono - is very keen to onboard new adopters of the packaging, so he probably will help. After the initial setup it is mostly an automated process for future releases.

The pros of appimages is they don't need any infrastructure in the system to work, as opposed to snaps or flatpaks downloading gigabytes worth of packaging ecosystem. Appimages just start on most distros, similar to .dmg on Mac.
Also you can easily force appimages to use their settings in their own config folders, making the whole thing portable and movable. Similar to portableapps in Windows.

[izzylaif]

I went ahead and created an appimage. It worked with only one hiccup - the application reads otpclient.ui and shortcuts.ui from hard-coded absolute path /usr/share/otpclient so I had to put those files in that path, and the appimage launched.
if you could change that to relative to the application, creating the appimage will be a breeze

[paolostivanin]

Sure, it shouldn't be an issue. A couple of questions:

1. what's the best path for an Appimage for the UI files?
2. can the Appimage read the ~/.config folder or is it like flatpak?

[izzylaif]

I've attached the compiled one.
otpclient.AppImage -> that the executable

If these folders are present near the executable:

otpclient.AppImage.home
otpclient.AppImage.config

the appimage will use those instead of /home/user/ and /home/user/.config
making the application portable. You can out it in a thumbdrive and use on any machine with all your settings.
If they folders are not present, the appimage will use the user home folder instead.

If you run the appimage, it will unpack to /tmp/ i.e. /tmp/.mount_otpcliXYZ. The XYZ changes everytime.
In this folder, the .ui are actually present in /tmp/.mount_otpclioXYZ/usr/share/otpclient and the variables are exported by AppRun file (inside the appimage or the /tmp when run).
However otcpclient seems to want them in absolute path. I believe you have $PREFIX set to root/usr or something like that.
So basically all that is needed to do is change that absolute path to relative to the application.
Currently, to run the appimage provided you actually need root/usr/share/otpclient/.ui files to exist. If you run the appimage from console without those files in place you will see an error
`Setting $HOME to /mnt/TEST/OTP/otpclient.AppImage.home
Setting $XDG_CONFIG_HOME to /mnt/TEST/OTP/otpclient.AppImage.config

(otpclient:3197): Gtk-ERROR **: 13:53:32.448: failed to add UI: Failed to open file “/usr/share/otpclient/otpclient.ui”: No such file or directory
zsh: trace trap (core dumped) /mnt/TEST/OTP/otpclient.AppImage
`

Hope that make any sense

otpclient.zip

[paolostivanin]

I see, thanks! One question: isn't there a recipe (like flatpak and snap do) for building an appimage?
While I appreciate your effort (really, thanks a lot!), I don't really like to publish binaries built by someone else :) I hope you understand.

[izzylaif]

neither do I want to be a maintainer or trust any other packager. that's the whole point why I approached you to generate an official appimage.
The recipes are .yml files. I don't have the yml for otpclient, but here is an example for chrome
https://github.com/AppImageCommunity/pkg2appimage/blob/master/recipes/Google_Chrome.yml

I also compiled a much smaller version which runs just fine
otpclient.zip

[paolostivanin]

Thanks!
I don't really have a lot of free time these days, so I prefer to focus on code rather than on yet another packaging format.
I'll leave this open for contributors though 😄

[izzylaif]

@probonopd we summon you

[probonopd]

As @paolostivanin wrote, he prefers to focus on code rather than on "yet another packaging format" (although I wouldn't characterize AppImage as just that). As a matter of policy I am happy to help upstream application developers who want to build and support AppImages.