Although it proved possible to build a snap image for SWI-Prolog on Fedora, snap is primarily a Canonical product. Flatpak is similar and promoted by most Linux distributions. That made me think to provide a flatpak image for SWI-Prolog.
The build works fine using the current swipl-devel.git version (a patch was needed because all files in the flatpak have their modification set to the Unix epoch and this was given a special meaning in the file admin of SWI-Prolog).
Does anyone here have experience with Flatpak and is willing to help to turn this into a properly working release on https://flathub.org/? Some issues that need attention
As is, the flatpak linter gives some errors and warnings.
The flatpak version currently lacks jpl, odbc, bdb and native UUID.
It is currently about 25% slower than the natively compiled version. I suspect that is due to the CFLAGS that are eventually used. Gcc 14 that I’m using for native compilation can’t be that much better than gcc 13 used by the flatpak sdk.
How can we start either swipl-win (Qt console) or swipl (in terminal)?
What should the sandbox permissions be?
It has Python and (thus) Janus. How much use is that? (How) can people add Python packages to this version?
The flatpak is fairly limited as well.
Flatpaks are not meant to be used for CLI programs, nor is it possible to have multiple commands (like the terminal and qt-console).
The sandbox permissions are editable, so it would be fine to find a sensible default, and let users override them.
Regarding python, if you were to bundle it in the flatpak it would not integrate with the system one, so it wouldn’t be too useful.
Having said this I can give it a look and see if some of the issues are avoidable.
To publish it it might have to default to the GUI (qt) version.
Thanks. Flatpaks seem to handle CLI applications just fine. At least, if I make swipl the command, it just works. Only, the way to run is not so nice (flatpak run id [arg ...]) As with the snap, making swipl-win the main executable seems the most sensible. That works just fine.
Finding a sensible solution to use Python, Java, odbc, etc. would be nice. But then, we do not have a solution for that for snap as well and as I understand it, the MacOS bundle already has some problems here and it is likely to get worse. Distributing software doesn’t get any easier
If you have time to have a look and give some comments, please do. I started a freedesktop MetaInfo file. That still has to be finished and put into some sensible location.
With a metainfo file, and a .desktop launcher (for the default swipl-win) the other warnings have been removed already.
The x11 warning simply requires replacing --socket=x11 with --socket=fallback-x11 (since the default is wayland).
Once it works we can then open the PR on the flathub repo on github, so it appears on flathub.
The python, java, odbc, … issue is harder to solve.
With the snap we could make it classic, so it has access to other programs installed (e.g. python/java), with the flatpak I’m not sure that’s possible. There are limited ways of breaking out of the confinement, but nothing as broad.
It’s possible to run host programs, by giving special permissions then running flatpak-spawn --host <command>, but I’m not sure that’s enough.
That unfortunately is not true. swipl-win is a Qt application and what would run fine with --socket=fallback-x11. SWI-Prolog’s only GUI tools are plain X11 though. So, I think the option is to use --socket=x11, forcing Qt to use X11 or give both, allowing Qt to do its thing and Prolog as well (X11).
Each has its own problems. Python is inside the kde runtime, but this does not need to be the same version as on the host. As we link to libpython<version>.so and we do not know which version runs on the host, it is practically impossible to use the host version. Possibly we can install Python packages that use the Python of the Flatpak? That would at least deal with half the problem. Java is not in the kde sdk. It we have a way to link in host .so files, we are fine though as the JNI interface is binary compatible between Java versions (as opposed to Python). ODBC is not in the sdk either.
There seem to be a whole range of flatpak types though. Some of the naming seems to suggest you can use one flatpak as a plugin to another. If that is true, there could be solutions?
I agree that the best step forward is probably to fix the MetaInfo and .desktop issues, get it accepted on flathub and see from there were it goes. That should probably be with the next release as they seem to like release files and the current release does not run in a Flatpak
So far, I like the fact the SDK poses far fewer problems than building snaps and is a lot quicker.
Ah ok. In that case we could remove the wayland socket, as that would not be used in theory. I don’t think it’s used for anything else (Sandbox Permissions - Flatpak documentation)
The issue using the python version in the runtime is that everything would need to be run in that runtime, and that might not be ideal (if a program makes use of other libraries).
There are also java (openjdk) runtimes, so one thing that might be feasible is to add those.
It might be feasible to add them as non essential dependencies, using plugins/extensions (Extensions - Flatpak documentation).
It might also be possible to add the filesystem access to the necessary host .so files.
Mainly added the appinfo/desktop/icon (from the snap). It can be changed later.
Haven’t looked at the extensions much, but there are other flatpaks that can be used as a reference for that.
It works if I manually clone the repository and run from the local version, but I get this error (at runtime) after building with the github repository as a source instead of a local folder:
ERROR: /app/lib/swipl/library/predicate_options.pl:53:
ERROR: with_mutex/2: C-stack limit (8,388,608 bytes) exceeded.
ERROR: Use the shell command
ERROR: /app/lib/swipl/library/dialect/swi/syspred_options.pl:42:
ERROR: sig_atomic/1: C-stack limit (8,388,608 bytes) exceeded.
ERROR: Use the shell command ulimit -s size to enlarge the limit.
It continues reporting issues like this, and never gets to a prompt.
Thanks. I was planning to take the route to add a MetaInfo file and generate the desktop info. I have a basic setup of that, but all should go to the right place. I think the MetaInfo should get some place in the main repo rather than the Flatpak
repo, no?
It should work if you use the HEAD of swipl-devel.git. The critical patch is dd7f4bdcaeec01f3c555d30a160de16195af190c. It appears Flatpak sets the modification time of all files to 0 (Jan 1 1970), but SWI-Prolog used the 0 value to indicate the source file was not loaded. So, it keeps loading in a loop until it runs out of stack. That patch keeps track of the loaded status in a flag rather than misusing the time stamp. I was still naive when I wrote that
P.s. What should be the application id? I thought that should be org.flatpak.swi-prolog, but I now think that flatpak is not needed there. Than org.swi-prolog.swipl-win would make more sense, but it the MetaInfo checker tells me that dashes are not allowed in application ids
The desktop/icon/metainfo can reside in the main repo, I added them there for testing.
The metainfo has to respect the same rules as the flatpak yml regarding filenames (the application id), and should be installed in the correct destination (through cmake?)
The other thing I added (for which I wanted to use the github tags) is to get flathub to automatically generate a PR on a new release (tag), to check that it builds correctly. Then the new version can be automatically or manually merged.
I can open the PR on flathub, so it starts building as it would on their infrastructure, to test it.
Then we can always move the desktop/metainfo/… to the main repo later.
The only thing to figure out before uploading is the name.
If you think org.swi_prolog.swipl-win is more descriptive of the package then it’s fine, and it would respect the requirements.
I doubt. It keeps the route for a non-Qt version as org.swi_prolog.swipl open. I have no clue how useful that is though. Do what you think is best. I guess it is not possible to have two .desktop files for a single Flatpak?
As you mentioned you can run other commands via flatpak run --command=... but it’s not really the intended use.
An alternative is to keep the non-qt version as default, adding terminal=true in the .desktop file.
That makes it so when launching from the desktop menu the terminal is opened (as if opening a terminal and running swipl)
I thought about that as a possible second .desktop. As that doesn’t work and I think the flatpak first of all targets new users, I think the Qt console is as good as we can do.
One thing I noticed is that the qt ui doesn’t switch to “dark mode” properly.
It works if I run use_module(library(theme/dark)).
One possibility is in the UI startup code would be to read gsettings get org.gnome.desktop.interface color-scheme from shell, and if the output is prefer-dark then load the dark theme.
Just a thought.
Is it possible to build the GUI separately from swi-prolog?
If so it could be a good idea to have both a “base” flatpak with just swi-prolog, that can be easily (mostly) integrated with editors or other programs (e.g. it would be possible to distribute a program running on swi-prolog as a flatpak using that as a base). One of these programs could be the graphical version.
The graphical one could still be the “user accessible” version, called swi-prolog, and the other would be org.freedesktop.Sdk.Extension.swipl (or swi_prolog).
I have this “base” image built and installed at the moment, and it can be loaded in editors.
This would be nice not just for flatpack but also regular packaging. swipl-win is pretty nice as a quick way to a toplevel without requiring a terminal, but right now it’s not an installable on most (all?) distros (except through snap/flatpack I suppose).
If it was its own build it’d be much easier to package it separately.
I’m pretty reluctant. The build infrastructure for the extensions is based on properties of the core build and quite a bit of generic stuff that is in packages/cmake. Untangling all that is probably a lot of work If possible, I’d like to think along the lines of the Debian package, where the system is built as a whole and subsequently a number of apt packages are created by exploiting the installable subcomponents defined by CMake. I.e., after building it runs a sequence of
Install component X
Package component X
I do not know whether all packaging systems can do so. The advantage of how it is now is that it is easy to configure and build the system and its extensions from source and a lot of double configuration checking is avoided.
It would be trivial to create swipl-win as an additional apt package. Possibly we should do so. I don’t know. You want the app for MacOS, snap and flatpack as an entry point. I build it, but I barely ever use it as the terminal is rather poor compared to e.g. terminator. Many others use Emacs for running Prolog.
Going for split output instead is fair for normal packaging. Though that won’t help with flatpack I imagine.
I don’t see any serious prolog developer use swipl-win for a long period of time, but for a novice it’s one less barrier to get something up and running that resembles the textbook/tutorial.
By the way, one odd thing I’m noticing about swipl-win is that it doesn’t appear to be using tcmalloc.
