The sorry state of snapping Qt5 apps

snapcraft
1

I think packaging Qt5 snaps currently is not really great. What the way others actually use for their Qt apps?

There are a couple of options I am aware of, all with drawbacks:

  • Use the kde-neon extension: This is the currently recommended approach. The downside is you are stuck with a nearly 4 year old version of Qt5. Also it depends on kde-frameworks-5-core18, which is only available for amd64.
  • Use a newer kde-framework part, e.g. there is the kde-frameworks-5-qt-5-14-core18 with newer Qt: This works, but one needs to replicate a lot of the boilerplate that kde-neon extension offers. Also it is still limited to amd64.
  • Include Qt5 in your snap: This gives the most flexibility. But it makes the snap much bigger (a snap already easily becomes a >100 MB monster, no need to make this even bigger), requires you to deal with building Qt5 and again all the boilerplate to make the snap use the proper locations on launch.

To be honest I find none of the above solutions really satisfying. On top of this there are issues like Snapped PyQt 5.15.2 application hangs on QNetworkAccessManager .

I like the idea behind the kde-neon extensions for its simplicity in using it. In theory this lets me focus on packaging my application itself. Also it is promoted as the recommended solution, which makes this look attractive at first glance. But it is not really being made clear that it is limited to amd64, and if you need newer Qt you are out of luck.

Any recommendations how to best deal with this (having a newer Qt version, being able to provide a snap for other architectures) without reinventing the wheel?

3 Likes
2

There are a couple of other solutions you could look into:

  • wait for the core20 version of the kde snaps and extension, that should be coming soon and at least add support for arm in the near future.
  • help the kde team to bootstrap this faster.
  • create your own Qt snap using the content interface to distribute your kde related applications. Same publisher snaps can do this at will.

These options are not turn key solutions today, but keep in mind that these platform snaps have a team behind them, it Qt or someone people trust with Qt wants to own something like a Qt platform snap, that would be most welcome.

2 Likes
3

Thanks for the suggestions. Probably have a core20 version of the kde framework and kde-neon extension is the most promising here, hopfefully with ARM support someday. At least I think the extension gives currently the best experience for packagers in regards of using it.

I also saw this very similar thread:

Same issue: How to get a newer version of Qt5. There it is suggested to use a PPA, maybe another thing to try, but seems to depend on a preview feature of snapcraft.

Currently I try to get this to work using the deprecated desktop helpers using the core20, but the resulting build is giving me other headaches :(.

As I am dealing with only a single application that’s about the same as bundling this into the snap.

4

Perhaps the qt platform and app snaps (via content sharing) I put together a while back may be of interest.

1 Like
5

I understood that nothing will happen in near time since kde-neon maintainers probably doing their extension only for their apps and Qt folks aren’t interested in maintaining a snap extension. Since no one will allow maintaining such an extension for random people, there are no hope that the situation will improve, so I switched to building Qt in snapcraft.yaml.

2 Likes
6

Thanks for sharing. I actually think I will give this a go and settle with bundling Qt in the snap. As proper Qt version often has been quite important to address bugs I think it makes sense. After all bundling Qt is also what we e.g. do on Windows and macOS.

1 Like
7

That’s where I am effectively too (as in, bundling the more recent Qt so’s), though in a “don’t touch it as long as it works” trial-error way. I am both using the kde-neon plug, which yields a few UI subtleties, e.g. the mouse cursor/icon becomes modern, and am deploying (many of) my Qt .so’s that PyInstaller pulls together for a simple build. I found about 60 of the PyInstaller’s full choice were not actually used, and thus got excluded in the end - I mean stuff like libQt53DAnimation - the app still works, so in total I am well below 100 MB with my “zipped” as well as snapped setups. (Probably doesn’t matter too much, but I use PySide2 wrapping Qt5.15.2 )

I am absolutely unaware of the risks I take in this possibly nutter approach, but sharing the pain might be a relief on its own for you :slight_smile:

On the other hand, thanks for raising the topic, I will follow!

1 Like
8

That summarizes it very well. I was absolutely happy when I had this running with kde-neon and the entire setup turned out to be rather simple and easy to maintain. Until I came to the point were I need to update Qt to keep it working :frowning:

Actually using PyInstaller to bundle the necessary dependencies is a very interesting idea. I had not thought about this yet. As we use PyInstaller to build the packages for other operating systems this could actually simplify things. Do you have an example how you do this in combination with Snaps? Or did I misunderstand and you either use Snaps or a PyInstaller created bundle?

Actually it is, thanks a lot :smiley: I try to like snap as a packaging format, but somehow the predominant feeling I have is frustration. I fear that shines through in my posts. For now I just want to find a working solution to this. As it currently stands I am looking towards hours of trial and error to find the best approach. Once I find the time to do this and get a satisfying solution I’ll post it here.

9

Hello! Sorry the slow reply, I am trying to do some quite immersive coding sessions.

Firstly, I do use almost all things that seem to contradict each other, it is very much a frownable process - but I’ll detail it briefly, and then you might be quicker to find some time to evolve it into something better. (Sorry, no full example yet. I’m on the PySide2/LGPL train at this point, the code is not intended by default to be public, and even if I’d like to share it does need some care.)

Remark: In fact, my Snapcraft experience is not that bad at all, I had way worse times before…

… extremely weird situations with packages not liking each others’ versions in PyInstaller (my deepest fear was getting in an irresolvable situation where package1 both needs to be up and downgraded ~ possibly goodbye linux version), modules not being detected as required, odd type safety requirements in Cython. Okay, it’s surely a lot easier at least on Win, but snapcraft felt relatively good, I guess they’d just need more people for these half-external maintenances.

My horrible process (“don’t try this at home”) is so horrible and long, I decided to attach it, then realized I can’t. Please check it out at your own risk!

So how things shouldn’t happen

  • I use a Ubuntu 18 box (‘build PC’) hosted on my dev. PC to build the snap I believe this is relevant as the newer Qt .sos within PySide2 will then have a (better, 0 < 1? :slight_smile: ) chance to be compatible with core18 I like the VM as I can just run my app, pdb it if needed… + I’m not feeling lost when it comes to modifications, and it effectively gets quickly tested where its bound to be deployed in a sense anyway.

  • pull over the code, (clean and re)create a build-dedicated virtualenv (- mostly unnecessary: verify that the project runs well from source code under the venv but whenever it is necessary, I forget to do it it mostly ends up being a good place to fall back to if things go wrong)

  • build ‘raw’:

    • PyInstaller does as setup.py tells it to, and takes care of normal duties (AFAIK wrapping the venv in the app executable, collecting whatever it sees needed) + in my case there’s a preceding cythonization result is in ‘dist’ directory

  • remove unnecessary .so’s (I’ll add that list too)

  • update the mysnaps/ (=$project) directory:

    • copy the entire remaining contents of the dist directory into $project/bin
    • also copy miscellaneous stuff (icon, desktop file in my case)

  • build the snap

    disclaimer: I do use destructive mode

    “snapcraft --destructive-mode Destructive mode. Designed to be used in temporary/short-lived environments, such as on a CI system, because the build could contaminate the host build environment.”

    (only my system isn’t short-lived :slight_smile: although I guess side effects could be eliminated to a degree if I kept reverting to a snapshot - so far didn’t seem necessary, I am also packaging a simple app)

    the reason for this is I am quite stubborn at using VirtualBox, but the nested mode (?) although switched on, didn’t want to pan out and then neither did the MultiPass, and I got very much fed up with rebooting into another OS. Stopped halfway to trying it under VMWare…

    (but then this strategy might fit e.g. GitHub’s CI consistently with other platforms?)

    (another reason could be startup time + the ~10+ GB that the multipass env. eats up otherwise)

The files I remove: https://gist.github.com/brezniczky/d8c42b7c52f67a4f89d4623660f049dc

The very slightly redacted snapcraft file: https://gist.github.com/brezniczky/77b860c9b43d8534ab1f42e15666c691

1 Like
10

To give this thread some closure:

For my use case I switched back to using desktop-helpers for the snap at https://github.com/phw/musicbrainz-picard-snap . Yes, the resulting package is larger, but it works and makes it available for other architectures than just amd64.

Also kde-frameworks snap is now also available as a stable release. I guess that makes it an option again to use. I haven’t tried it and don’t know whether kde-neon extension would already work well with it, but it is an option. But for my part I will stick with desktop-helpers for the foreseeable future.

2 Likes
11

I don’t have any problems since moved to self-building Qt with desktop-helpers, it works wonderfully. And I even can patch Qt to fix some snap-related things that upstream Qt doesn’t want to fix.

1 Like
12

It’s a pity kde-neon extension experience is so terrifying, so I think it shouldn’t be positioned as a recommended way to snap Qt applications any longer since KDE maintainers definitely maintaining it only for their own purposes (e.g. they even don’t provide the standard qgtk3 platformtheme plugin). Therefore, there should be some minimal extension that gives all the advantages of extensions (e.g. font hooks) without pulling neither gnome or kde libraries.

3 Likes
13

Am I missing something or are we almost there @ppd ?

As per Allow Global auto connect for kde-frameworks-5-96-qt-5-15-5-core20 - #5 by ppd I understand that now there’s a kde-neon extension with a “recent” Qt5 version and arm64 support.

1 Like
14

You’re quite right, we’re pretty much there. KDE has been publishing arm64 builds of most of its snaps (and they work!) for some time. As the updated kde-neon extension has already been released to stable, this is now available for all users without extra hoops to jump through.

Also, on core22, a more modern architecture will hopefully be adopted for the kde/qt extension that allows the user to switch out the content & sdk snaps easily. A platform based on Ubuntu’s repositories or a Qt6 snap are things that could then be available as alternatives to the standard KDE Neon snap.

3 Likes