Just curious curious
this is kind of like asking on the debian list if there are plans to support rpm’s inside of deb packages … (or vice versa on the fedora list to support debs inside of rpm packages)
appimage and snap are two completely different packaging formats implemented in different ways but achieving similar results of distro independent packaging and delivering of software.
there are no ways to “support” one inside the other.
Is it? I mean since a package is just a set of files to both appimage and snap the problem can only be running it. And since AppImage is written in C how hard is it to have it as a dependency and call its code?
you could surely try to create a snapcraft plugin that tries to re-pack an appimage into a snap though, if you feel like …
i’m sure the snapcraft team wont refuse a working patch 
Oh I see. The integration probably isn’t needed since both formats are portable as I understand (though snaps for classic distributions depend on snapd package). The tools that can be shared (theoretically) are building from the same configs/with the same plugins and publishing to the store.
What would be interesting (and maybe worthwhile) would be to package the optional appimaged daemon that registers AppImages with the system as a snap. Anyone wants to give it a try?
3 Likes