While most people would associate Guix as an operating system,
it is designed to be used as a general package manager across different operating-systems.
One advantage of Guix would be for reproducability.
Any ideal packaging approach would naturally try to align between packaging silos, though this domain is usually fractured across silos.
Most likely I can think of termux (Android), gentoo Linux, Portable Apps (Windows), Anaconda, Conan. I probably know about more and I never heard about Guix.
It is a difficult story. Each of these package managers have their own features and guidelines as to how things are named and where they must be installed, while I’d like to have SWI-Prolog being as much as possible the same on all of these.
Luckily, most of these packaging systems now prefer CMake and the package definition mainly differs in how to get the dependencies.
I sometimes think it is time to have a meta-package definition that can be imported by many packaging systems. After all, the story is every time (1) these are the dependencies and (2) these are the build/install/test steps. Possibly extended by some specification on how the system can be distributed over multiple packages. The latter is already specified for SWI-Prolog as CMake installable components.
All these systems differ in the syntax they use and the names they give to the dependencies and whether or not a library is split into a package holding the shared object and a package holding the headers and static library (e.g., -dev for Redhat and -devel for Debian).
I can think of termux (Android), gentoo Linux, Portable Apps (Windows), Anaconda, Conan. I probably know about more and I never heard about Guix.
Story of the world, I learnt a few from your list too.
I strongly recommend Guix to those who enjoy control and ruggedness for their installations however (the people in that community are ace too).
Should there be integration of different package definitions in one location it shall be easier.
Some dashboard aggregator sites between known operating systems elude me as I type.
Naturally, there will be a variance of quality, if not risks.
Perhaps a RFC among community members to establish a passing audit of documentation being uptodate for different OSes and package managers would be interesting.
Its entirely possible that you have a core of Prolog users all using some niche.
[Maybe one day Ill create some parsing scripts to provide an overview (no promises).]
FYI, Im worried that the repo you cite in the build instructions for Termux may be experiencing bitrot (given that the repo hasnt been updated in 5 years, which even includes (potentially insignificant) divergence for the script ‘run-docker.sh’): https://www.swi-prolog.org/build/Termux.html
Edit:
There is this conversation thread concerning this package definition for NIXOS
As such, it is entirely possible to model and ideal that captures all the core facets of packaging SWI-Prolog (as well as other workflow matters) in Prolog,
and then provide the alignment to a coterie of high interest non Prolog based Prolog environments.
This PDF references a lot of features that could be apt for the problem domain of packaging multiple environments in Prolog:
Im aware that it has been used in the bioinformatics community.
In any case, there have been a lot of rumblings about complexity from Autotools, including the infamous use of it as a longplayed mechanism to inject an attack into the XZ compression utility.
I recall this solution mentioned on the Guix devel mailing list as an approach to simplify build instructions and avoid backdoors being added.
Not that Im fearful of Prolog based builds per se, but it is always helpful to mention good hygene approaches (and transposing to a simpler Makefile approach would be a stage for adapting scripts to a Biomake style).
Looking at the Guix package definition a question arises. I see it packages 9.3.8. This is a development version.
Guix is really not unique in this. It seems like a lot of distros and package managers are just taking the ‘latest’ version of swipl, not realizing (or not caring) that this is the dev snapshot, and the even minor numbers (so 9.2.x right now) are stables.
Do we want distros to package the development snapshots?
Also, looking over the build inputs in that Guix package definition, there’s a lot of dependencies missing. running a check_installation in the resulting swipl binary toplevel will probably issue a lot of missing component warnings.
I guess that is distro policy. Typically, the development snapshots are pretty stable. I’m still somewhat unhappy with the stable/devel cycle approach. Most serious developers are better of using the devel versions as they are typically more advanced and issues get fixed quickly. They break compatibility more frequently. Except for cases where compatibility is restored in the devel series, the stable version just combines all incompatible changes in one upgrade
If anyone sees a better release schema, please share. Note that the current policy is to release the devel series every two weeks, shorter in case of serious mistakes, longer if not too much happened. Stable updates typically last about a year, depending on developments, issues with the old stable and stability of the devel series. A new stable release typically gets some backports for serious issues. After a while this typically deteriorates because backporting gets too time consuming due to failing automatic merges.
Anecdotally, we did run into issues with TerminusDB in the past. I have no idea anymore what the specific issue was though. In general, I think having a stable version that only gets backports is a good thing. Especially for distros like Debian which allow minimal backport fixes after release (which is essentially what SWI-Prolog stable is) but not entirely new versions.
In a discussion around a PR in nixpkgs (where I raised the version from an old dev release to the latest stable at the time), the idea was raised to just package both and have users decide.
I was thinking of having a swi-prolog and a swi-prolog-next. So right now that would be version 9.2.6 and 9.3.9. NixOS works a bit like Debian in that it’s generally frowned upon to update package versions after release, except for versions that are just bugfixes and the like. I figure that after release (which will be in november), we can just have the latest stable + devel packaged as it is at that time. If, during the lifecycle of NixOS 24.11, SWI-Prolog 9.4 (or maybe 9.6 by that time) is released, then the package swi-prolog-next could be upgraded to that, as it’s kind of like a stabilization of 9.3 (or 9.5).
TerminusDB always lagged several versions behind cause upgrading could cause Issues which we were not really willing to deal with. I doubt we were very unique in that.
But yes, in general it would be good if a lot of people ran these development versions so that bugs get spotted. I guess that means they have to be packaged too, at least in rolling distributions or other types of distributions that don’t freeze the version for years (looking at you Debian).
It makes sense to me honestly. I just think that many distros that are now packaging a dev version don’t realize they’re doing so.
As a functional package maanger, Guix, like NixOS is great at rollbacks so the threat from developer snapshots are lesser than other OSes.
Also, looking over the build inputs in that Guix package definition, there’s a lot of dependencies missing. running a check_installation in the resulting swipl binary toplevel will probably issue a lot of missing component warnings.
Its entirely possible that the dependencies are implicit as a consequence of other dependency ‘inputs’ being referenced.
It would be nice to validate this eventually.
And Guix packages can be used in NixOS . That’s the joy of hermetic package builders.
Just be aware that SWI-Prolog will happily build with a limited feature set if the dependencies aren’t present. That doesn’t matter as long as you don’t need those features, but it can still lead to weird inconsistencies between distros.
For example, It doesn’t seem like the current Guix packaging is building with tcmalloc as the allocator. This dependency is unlikely to be pulled in by any of the other dependencies. The impact of a different allocator is subtle but it is there.
I can think of termux (Android), gentoo Linux, Portable Apps (Windows), Anaconda, Conan. I probably know about more and I never heard about Guix.