Pack Prolog version dependencies?

Request For Comments
1

Recent versions of the pack system allow putting constraints on the Prolog version, so the pack won’t install on incompatible Prolog versions. It allows for

  • prolog Cmp Version
    Demand a Prolog version (range). E.g. prolog >= '9.3.8'
  • prolog:Flag
  • prolog:Flag(Value)
  • prolog:library(Lib)

@peter.ludemann stumbled on a problem where we would like to demand >= 9.3.8 for the development series and >= 9.2.6 for the stable series. How should we deal with that. Possibly related is whether we make a new format facilitate other Prolog systems?

Note that a boolean expression is not so nice. It needs to express 9.2.x with x>=6, or >= 9.3.8 (which will also cover 9.4.x and 9.5.x, etc.) You’d get something ugly like this:

(prolog == '9.2' && prolog >= 9.2.6) || (prolog != '9.2' && prolog >= '9.3.8')

Any ideas for a nice representation that ideally also allows to specify the dialect, so we can express e.g. “SWI-Prolog > 9.3 or Ciao Prolog > 1.2”?

2

[edit: embarassingly i didn’t read the opening properly, and didn’t understand that we can already specify dependencies to swipl versions, we just can’t deal easily with the ‘two tracks’ approach to swipl versioning without big expressions.]

I like the way I get to specify dependencies in rust, through the Cargo.toml file: Specifying Dependencies - The Cargo Book

it supports several syntaxes, among them something like

SWI-Prolog = "^9.2.1"

Whick says that 9.2.1 is the minimum version, and other than that, we’ll accept any 9.2.x where x >= 1.

We could have several such dependencies for different prolog environments, and maybe swipl-devel is just its own ‘variant’?

3

I’m glad this is being looked into. I was having similar concerns about what to do when a library depends on some feature that just isn’t going to be present.
Note that ‘feature not present’ is not just about the version though, since features can be turned on or off depending on the build. Not sure if we want to deal with that one, but we might want to specify a list of required features instead of, or in addition to, a swi-prolog version number. [edit: is this what prolog:Flag is about?]

Version dependencies would also be nice between packs.

4

That is the same as this in pack.pl. I’m happy to add '^9.2.1' as syntax, but I can’t really see the added value.

 requires(prolog >= '9.2.1').

It is not really enough though. Multiple requires/1 statements act as conjunctions, i.e., they must all be true. We surely need something for disjunctions. As is, that is not provided.

That is the line I’m thinking along. This is a disjunctive statement though. How do we fit this into the syntax of pack.pl?

What do you mean by a library here? System library or part of an application (or pack)? As for Prolog, features are typically represented by flags. That is where prolog:Flag comes in: you can ask e.g., prolog:unbounded, which is the same as prolog:unbounded(true), which means current_prolog_flag(unbounded,true) must succeed. You can also ask prolog:library(assoc) to demand the presence of this library. Packs “provide” tokens at a version. They always provide the pack name at the version of the pack. In addition, they can provide any token at any version using (in pack.pl) e.g.

 provides(email_client@'1.0').

That (in theory) allows for multiple packs to “provided” some abstract feature. I don’t think it has ever been used :slight_smile:

Note that you can ask for a pack at a certain version using

 requires(mypack >= '1.1.2').

When installing a pack, SWI-Prolog searches for the most recent version for which it can make all requirements true. So, if the new version of a pack requires some minimal Prolog version, older Prolog versions will install the old version.

Any comments, notably on best practices not covered are welcome. The main issue (as I see it) is now dealing with Prolog series and dialects. Note that this is easier than package requirements as the running Prolog system either satisfies or does not satisfy the requirement. I.e., unlike packs, there is no way to fix a failed requirement on Prolog except for installing one that satisfies the requirements.