I have a few problems with FreeCAD’s snap package (https://snapcraft.io/freecad) and would like to start a discussion on how to improve from here. Experience wise, I’m the author of SolveSpace’s snap packaging (https://snapcraft.io/solvespace).
Organization: The snap is not published by an organization account (i.e. “FreeCAD”), but by Jean-Marie Verdun (vejmarie). It should be transferred to such an account and vejmarie should then be added as a collaborator. Additionally, more than one person should have access to its administration interfaces to increase the bus factor.
Development: I have not been able to find the packaging’s sources. It goes (hopefully) without saying that this is far from ideal.
Functionality: The snap does not display fonts for me (Ubuntu 20.04) and is thus non-functioning.
Presentation: The store page has neither a proper description nor any pictures attached. The snap has no proper desktop-file set and is consequently not searchable in the user’s desktop environment. All far from ideal.
Packaging: The snap is not based on a current platform (core18 or soon core20) and does not employ best practice for desktop applications, e.g. using the kde-neon extension for an updated Qt and not having to bundle all Qt libraries. I couldn’t test any further, for the reasons outlined above.
Publishing: Currently, no nightly/daily/master builds are being published. The snap model with its channels would be very suited to publishing stable and experimental revisions at the same time.
I have sketched an implementation in my FreeCAD fork: https://github.com/ppd/FreeCAD/tree/snap/snap and it works well for me. Obviously, much can be cleaned up and improved. But for that we need a better structure and some healthy discourse.
If i look at your proposed snapcraft.yaml file it in general looks good to me. The one thing that i slightly worry about is building all the (heavy) dependencies. As that likely takes a very long time? For stable builds that likely makes sense. As for more frequent builds, if we would have working snapcraft.yaml in place and i guess would would be building only FreeCAD, providing the latest snap package should likely become a possibility:
Thanks for looking into this. Ultimately somebody needs to step in if they want to get things done.
I’ve never felt the need to use snaps since they appeared in Ubuntu, but that doesn’t mean that they don’t have benefits.
The current Debian/Ubuntu maintainer produces daily FreeCAD debian packages for Ubuntu, and the Conda maintainers do the same for AppImages, so the situation is good at the moment. Adding Snaps to the ecosystem would be good if somebody can put in the work to maintain them.
If you are able to, I suggest you document the process in the wiki, under packaging, so that more people can learn about it.
Split each bigger dependency into its own snap and either stage them together, i.e. merge them at build-time, or link them at run-time via the content interface (https://snapcraft.io/docs/content-interface).
Use what’s available on the base in use. In this case: core18 = bionic. We would change to core20 at some point.
Use the PPA as a source
That’s the reason why I spoke about increasing the bus factor. If we keep the package as simple as possible and also document the processes thoroughly, the packaging should be quite stable and easy to update.
That’s quite good indeed. However, I want to emphasize how much more accessible snaps are for novice users. They are just there in the software store on Ubuntu and no fiddling with PPAs or using outdated versions is required.
Hi ppd, thanks for your effort in improving the snap package.
I should have permissions to edit/etc the freecad snap as well as Jean-Marie, but I don’t see any options on the snap page itself, the interface seems different from when I looked at it.
You can log into the Snap Store with any Ubuntu One account. I don’t think a launchpad team is represented by one though. So I’d suggest creating a dummy account with the appropriate display name “FreeCAD” or “FreeCAD Maintainers”.
And another thing I’d like to say: I’m not looking to compete with vejmarie’s packaging, I just wanted to get in touch with him and the FreeCAD maintainers.
vejmarie’s input is crucial, as he has the most experience with the particular difficulties and pain points regarding this snap.
Great, dashboard.snapcraft.io is what I was looking for, for some reason the “Developer account” link doesn’t guide me towards there…
[quote=“, post:6, topic:41318”]
I agree re: the organizational account as owner of the snap. It would be nice if we could re-use > https://launchpad.net/~freecad-maintainers
[/quote]
You can log into the Snap Store with any Ubuntu One account. I don’t think a launchpad team is represented by one though. So I’d suggest creating a dummy account with the appropriate display name “FreeCAD” or “FreeCAD Maintainers”.
Hmm, is there no formal way to have an organizational account? I don’t really like the idea of shared credentials being passed around with snap publishing powers since snap has no way for end-users to turn off receiving updates AFAIK.
To me it looks good for now, hence if you will go ahead an make a PR, adding snapcraft.yaml, that likely shouldn’t represent any big problems. The decisions, regarding enabling the stable/per-commit builds on Snapcraft, from the FreeCAD GitHub repo, that can be made after. If it really comes down to pressing on a few buttons, like mentioned in the above blog post, i don’t see any special reason, on why not giving it a try.
Reusing all that great Debian/Ubuntu packaging from the PPA + more recent Qt from KDE Neon seems the way to go. Let’s KISS and only build the bare minimum.
I will go over all remaining optional dependencies and make sure nothing’s missing. I will temporarily publish the snap as “freecad-ppd” in the Snap Store for anyone who wants to try it out.
Of course, I’m still eager to hear from vejmarie. After all, he’s the maintainer
We can add some auto scaling via QT_SCALE_FACTOR (scales fixed size fonts) or QT_AUTO_SCREEN_SCALE_FACTOR (does not).
You can play around with setting QT_AUTO_SCREEN_SCALE_FACTOR=1 and running freecad-ppd.freecad and report whether you like it better. Or try QT_SCALE_FACTOR=2 freecad-pdd.freecad or similar.
The snap is based on code in the snap-ppa branch. Naturally, this means that those commits are not in the master branch and thus the hash differs.
One key-difference is the platformtheme in use. The snap has access to:
/snap/kde-frameworks-5-core18/32/usr/lib/x86_64-linux-gnu/qt5/plugins/platformthemes$ ls
KDEPlasmaPlatformTheme.so libqxdgdesktopportal.so
You’re probably using something else. We need a little fine-tuning for Qt. Both appearance-wise and regarding the file dialogs. They should use the xdg desktop portal.
