Closed jdferron closed 4 years ago
Based on the Appimage project's goals I'd be more inclined to go that route, or given the notes here on bundling Python packages into flatpaks (https://gist.github.com/ForgottenUmbrella/ce6ecd8983e76f6d8ef47e07240eb4ac#flatpak), maybe even snap over a flatpak:
Unfortunately, with Flatpaks, using Python is cumbersome: flatpak run --command=python DBUS_APP_NAME --ARGS.
Given that we're optimizing the effort that the end-user must do, I'd be inclined to pick a solution that is easy to setup and maintain for me as well.
Any preference between appimages or snaps if flatpak won't make the pick? Or is there other details to consider why a flatpak in particular would be good here?
snap is fine as it is also supported by Ubuntu.
I've now uploaded an AppImage and a Snap package to the latest release. v1.2.0 release
Both are somewhat experimental since I haven't gone through extensive testing.
The appimage is built on Kubuntu 19.10 so it's unknown what older distributions it will run on. It did run on my Manjaro machine.
The snap was necessary to build as a classic snap since the strict confinement brought up numerous issues that I can't solve with little effort ( = soon ). So no snap store release for now. I'll try to get the confinement working, but it has a fairly low priority right now. Maybe for 2.0 release.
Edit: See readme for note on snap installation.
Based on the discussion had here https://forum.snapcraft.io/t/issue-establishing-dbus-interface-with-org-kde-plasmashell/14908 superpaper seems to be a bad fit for a strictly confined application. At least in the case of Snaps, superpaper falls under unsupported use cases. It seems probable that the situation would be similar with a flatpak as well. Thus I'm essentially forced to use either native packaging / PyPI / AppImage.
Going forward I'll make releases for PyPI and as AppImages.
Requesting flatpak support for SuperPaper so that manual steps do not need to performed to install it.