Did you know ... Search Documentation:
The contents of pack.pl

A pack must hold a file named pack.pl in the toplevel directory. Note that the toplevel directory of the archive can be ., <pack> or <pack>-<version>. The file pack.pl contains ground Prolog terms. The terms below are defined. Of these, only name and version are obligatory.

name(Pack)
Name of the pack. This must be provided. Must consists of ASCII characters that can always appear in filenames. Due to case (in) sensitivity characters, use lowercase letters. Use _ as word separator.
title(Title)
Free style description. Please limit to ASCII to avoid problems with character encodings.
version(Version)
Current version of the pack. This is an atom consisting of integers separated by dots (.). E.g., '1.1.2'. This must match the version in the file name of the pack archive (e.g., mypack-1.1.2.tgz).
author(Name, Email)
Provides name and email address of the author. If there are multiple authors, include multiple of these terms.
maintainer(Name, Email)
Current maintainer of the package. May appear multiple times.
packager(Name, Email)
The person that created the package.
home(URL)
Home page URL providing more information about the package.
download(URLPattern)
Principal download URL for the package. Must be an HTTP URL. May contain a file wildcard pattern to match multiple versions of the package. Patterns are used by pack_upgrade/1 to query available package versions.
provides(Token)
Package provides Token. A token is an atom, describing some property of the package. A package always provides its own package name. A pack may provided multiple tokens by repeating the provides(Token) term.
requires(Token)
Package requires the presence of another package that is named Token or provides Token.
conflicts(Token)
Package cannot be used together with Token. Currently unused.
replaces(Pack)
Package replaces Pack. This implies that installing this package removes Pack. May be specified multiple times.

Here is a simple example

name(demo).
title('Demo package').
version('1.2.1').
author('Jan Wielemaker', 'J.Wielemaker@vu.nl').
See also
- Pack.txt
Tags are associated to your profile if you are logged in|Report abuse
Tags:
  • doc-needs-help
LogicalCaptain said (2021-02-08T08:15:10):0 upvotes 0 0 downvotes
Picture of user LogicalCaptain.

Pack or Package?

"Pack" and "Package" seem to be used alternatingly. However. as i understand it:

  • Package: An official SWI-Prolog add on
  • Pack: An unofficial SWI-Prolog add-on

This page is about the latter.

Lead-in

It is unclear what this means exactly:

"Note that the toplevel directory of the archive can be ., <pack> or <pack>-<version>."

I suppose this is about naming the directory, but a directory can never be named `.`.

Name

Name of the pack. This must be provided. Must consists of ASCII characters that can always appear in filenames.

This depends on the underlying filesystem of course. A : is valid on ext4, but not on NTFS for example. Special characters SHOULD be avoided but characters beyond ASCII SHOULD be allowed. What will our Chinese friends say?

Title

Please limit to ASCII to avoid problems with character encodings.

That's an unreasonable requirement. We have been in unicode world 25+ years now. It would be much better to demand that pack.pl be encode in UTF-8. Or do it as for XML: have an encoding marker at the start of the file:

% Encoding: UTF-8

That would be pretty straightforward.

Also, I suppose the Title is a string or atom?

Version

Why not just state that semantic version https://semver.org/ should be implemented?

Then:

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

But this also allows the following:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.
Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3—-117B344092BD.

Tokens

provides(Token) requires(Token) conflicts(Token)

are interesting but to really make this work, one needs the tools (similar to the RPM database and the rpm command) and the associated documentation of behaviour & semantics. I don't think this is implemented? (Or maybe one could just piggyback onto existing package managers? In any case, it's a mountain of work)

All must be atom

AT least for now, pack.pl must be a stream of compound terms that will be read by read_term/3. No comments allowed.

In the source code of prolog_pack.pl, we find these typing requirements for the terms:

pack_info_term(name(atom)).                     % Synopsis
pack_info_term(title(atom)).
pack_info_term(keywords(list(atom))).
pack_info_term(description(list(atom))).
pack_info_term(version(version)).
pack_info_term(author(atom, email_or_url)).     % Persons
pack_info_term(maintainer(atom, email_or_url)).
pack_info_term(packager(atom, email_or_url)).
pack_info_term(home(atom)).                     % Home page
pack_info_term(download(atom)).                 % Source
pack_info_term(provides(atom)).                 % Dependencies
pack_info_term(requires(dependency)).
pack_info_term(conflicts(dependency)).          % Conflicts with package
pack_info_term(replaces(atom)).                 % Replaces another package
pack_info_term(autoload(boolean)).              % Default installation options

Version: Exact? Match?

Can I have a version string '1.0' and name the package with '1.0.0'? Must the match be exact?

Potentially missing

history(When,What)

Might be of interest to add history information to the pack.