--appimage-extract-and-run

[TheAssassin]

Docker is a very popular environment for building software, and also AppImages.

Due to our use of FUSE, AppImages don't directly run in Docker, which requires a simple but annoying workaround for every AppImage: the AppImage is called with --appimage-extract, and then, instead of the AppImage, squashfs-root/AppRun is called. This is normally just another line that needs to be added, but can get quite complex the more AppImages are involved, because then the squashfs-root directories need to be renamed, etc.

This is something that could be automated by us by adding a new option to the AppImage runtime: --appimage-extract-and-run. When this flag is used, the AppImage's contents should be extracted into a temporary directory with a predictable name (i.e., some value that depends on the AppImage file), the AppRun entry point should be called with the other parameters passed, and then the files should be cleaned up again.
In order to avoid having to re-extract all files on subsequent runs, we should introduce an environment variable NO_CLEANUP that, if set, should prevent the cleanup code from running. This is also what the predictable directory names are needed for.

This flag wouldn't only help our users, but also help us in our own Docker based build scripts.

[probonopd]

In an effort to keep the number of options and the complexity low I'd say ./some.AppImage --appimage-extract && ./squashfs-root/AppRun && rm -rf ./squashfs-root is preferable imho.

[TheAssassin]

@probonopd as pointed out above, this doesn't work in many cases. This doesn't add any noteworthy complexity, rather it forces us to refactor the runtime a bit, and greatly improve its code quality and structure.

The alternative is to provide some sort of shell script that automates this. But that doesn't make any sense. Aren't we user oriented? Users request this feature, after all.

[probonopd]

I think your main point is that instead of squashfs-root we should use something that reflects the name of the AppImage and thus would prevent collissions. Right?

[TheAssassin]

No. The point is that we should provide an easy, automated and reliable way to execute AppImages in Docker containers without needing the user to understand the problem and solve it using some script magic.

[probonopd]

What I want to avoid is "normal users" getting used to the idea that extracting an AppImage in order to run it is the normal/an accepted way of doing things. We are not makeself...

[TheAssassin]

That's a really vague guess from your end. I mean, "by default" this option is not used. A user would have to type a really long parameter to use it.

The benefits of this parameter outweigh the disadvantages greatly.

[probonopd]

I'd be OK with it as long as it is not documented in --appimage-help and similar places. We could document it in the message that appears when FUSE is not working (in addition to pointing to the FUSE page on the wiki). It needs to be clear that this is a fallback in case the normal way of operation is broken.

[TheAssassin]

Okay, well, I think that if you explicitly state it should only be used in case FUSE doesn't work, it could also be included in the help text. But in any case, I'll start working on this then. I already started to improve the code flow in the runtime a bit, but I'm still struggling to understand some ifs in the extraction code. But I will figure it out, I guess.

[TheAssassin]

So, I finally understand what that "extra parameter" in --appimage-extract did: It was some sort of "pattern" that one could pass to extract parts of an AppImage only.

My question is: do we really need that? In my opinion, it'd make more sense to allow overriding the default squashfs-root output directory. This'll also make development of the feature requested in this issue easier.

[probonopd]

My question is: do we really need that?

Sure! Do you really want to extract the whole AppImage just to get e.g., the desktop file(s)?

[TheAssassin]

I will restore the original behavior then.

[TheAssassin]

I'm finally done with this feature. It was a bit more work than expected, but I could fix some things in the runtime and other parts of our source code.

Also, I found a nice and working (verified) MD5 implementation which I included into our repository. This will allow us to remove the dependency on OpenSSL in libappimage (used for MD5 calculations during desktop integration).

Pattern matching has been restored. I actually documented this now, to avoid further confusion about the feature.

We're getting closer to a point where we could unit test the runtime.

[probonopd]

Great job, thank you very much @TheAssassin

[ChristianCiach]

It looks like --appimage-extract-and-run is not advertised by --appimage-help. Is this by design?

[TheAssassin]

@ChristianCiach #841 (comment).

[ahmedtds]

Not advertising it is a bad idea, stop being a nanny. I had to google for like 1 hour to find this solution. Why I had to do that? You should mention about it if FUSE fails or don't exist.

[probonopd]

@ahmedtds are you running in a Docker container? Or what else is the reason you cannot use FUSE?

[TheAssassin]

How is this relevant? The issue is that the option isn't documented anywhere outside this issue tracker, mostly because of your opposition in the comments here.

Simply adding this option to the help text and, more importantly, https://docs.appimage.org will resolve @ahmedtds's concerns.

[probonopd]

Btw, I am not against documenting it on docs.appimage.org if it is clearly explained that this is for Docker, Podman etc. and is not the genereally recommended "normal" way for running AppImages on (broken) desktops. Personally I am not using Docker, Podman etc. but it seems like people have issues using appimagetool.AppImage there, and need --appimage-extract-and-run as we never implemented container autodetection to make it "just work".

[soredake]

@probonopd not only docker, but also flatpak.

[suy]

FWIW, this is now documented, with both the command line argument and the environment variable. It's on the troubleshooting section: https://docs.appimage.org/user-guide/troubleshooting/fuse.html#fallback-if-fuse-can-t-be-made-working

This issue appears much sooner in a DDG search, though, so I hope the link is useful. ;)

[adelin-b]

I just found this option, its been weeks I had problem because some extension I use need to patch the appImage on runtime.
It is not documented:

 myappimage --appimage-help
AppImage options:

  --appimage-extract [<pattern>]  Extract content from embedded filesystem image
                                  If pattern is passed, only extract matching files
  --appimage-help                 Print this help
  --appimage-mount                Mount embedded filesystem image and print
                                  mount point and wait for kill with Ctrl-C
  --appimage-offset               Print byte offset to start of embedded
                                  filesystem image
  --appimage-portable-home        Create a portable home folder to use as $HOME
  --appimage-portable-config      Create a portable config folder to use as
                                  $XDG_CONFIG_HOME
  --appimage-signature            Print digital signature embedded in AppImage
  --appimage-updateinfo[rmation]  Print update info embedded in AppImage
  --appimage-version              Print version of AppImageKit

Portable home:

  If you would like the application contained inside this AppImage to store its
  data alongside this AppImage rather than in your home directory, then you can
  place a directory named

  /opt/cursor-bin/cursor-bin.AppImage.home

  Or you can invoke this AppImage with the --appimage-portable-home option,
  which will create this directory for you. As long as the directory exists
  and is neither moved nor renamed, the application contained inside this
  AppImage to store its data in this directory rather than in your home```

[TheAssassin]

Please open an issue in the new repository: https://github.com/AppImage/type2-runtime

[probonopd]

AppImage/type2-runtime#64