Hi!
I’ve been using a snap version of swi-prolog on ubuntu 19.10 for a bit now, to maintain consistency with the other systems running the codebase (macos installs via brew).
I wanted to know if there would be any interest in releasing a snap.
If possible, and if it’s something interesting I’d like to upstream it, and release it officialy.
2 Likes
Yes, please go ahead. Its not really needed on Ubuntu as there are PPAs for Ubuntu, but it should be a practical solution for many users on other Linux versions. The official docker container is a big success.
Great! I’ll open a PR then, and we’ll continue the discussion there?
The snap works now, and the main advantages over the docker image is x11 support and size (35MB atm).
The main thing to figure out is what permissions it needs if it is to be a confined app (the best solution, especially to enable easy cross distro compatibility).
For my use case I didn’t need much, but maybe it’s best if you have a look at that?
These are the supported interfaces: https://snapcraft.io/docs/supported-interfaces
For now I enabled: home (for access to non hidden home files), network, x11, desktop, desktop-legacy and removable-media.
I don’t know what it means to become an official snap. Any changes required to the source should certainly go through PRs. The stuff to build a snap can, I guess, be either a separate repository (as for debian and Docker) or it can be some files in e.g., the scripts directory. If you follow practices from other open source projects you are probably right.
The rights look fine for the core system and basic usage. Of course, the user may load extensions that need more rights. Is it even possible to load .so files into the snap executable?
You may wish to use the scripts/pgo-compile.sh you gain some performance 
Official would mean simply that it would belong to you, like you release the ppa 
The best way to do it would be to keep the snap package is to keep it in the snap folder (in the root of the repo), so that the build system can pick up any change and automatically build on any commit.
Then it would upload to the snap store, to the edge channel.
When you release a stable version (or beta) you can manually “promote” it on the store.
I hope I made some sense
The snap can load files from anywhere in the user home folder (any non hidden folders) and removable drives, even .so files, if they are in a compatible location.
I can look at it again if someone with a different use case finds issues!
If all fails it is possible to set it as a classic snap, which simply works as a traditional program, with complete access to everything (another one I support is https://github.com/ubuntu/ubuntu-make).
Most distros work with those as well, but there have been issues in the past
If that means I merely have to extend the script that published everything, that is fine with me. I would appreciate it if you can set it up
In the end, SWI-Prolog is a programming language and thus may need access to anything Access to sound and OpenGL are certainly done by some people. Whether that should be part of the snap rights, I don’t know. It also makes sense to minimise the rights to give people trust and tell the few that need all rights to build from source (which I guess is still a good plan for several scenarios).
sound and opengl can be added without too many problems. The thing that we could try is a confined snap, and if there are requests for more rights verify if it’s possible to add them or switch to classic.
In my case I installed my snap and for me it worked perfectly, and it worked without any intervention with the python bindings pyswip. But it’ll be different for everyone.
I uploaded a PR!
To anyone interested, what features should the snap include:
- Qt gui, debugger, …
- java bridge
- other
Keep in mind that any addition will make the snap larger in size, but it should be still smaller than the docker image.
Note that (I guess) including JPL also means including (a) Java 
Yes, it would mean including a version of jre/jdk depending on what’s needed at runtime