pack_install(..., [upgrade(true)]) doesn’t upgrade for both rdet and logtalk.
The work-around is to find all files and directories in ~/.local with the pack name and delete them.
$ swipl -q
1 ?- pack_install(logtalk, [interactive(false), upgrade(true)]).
pack_install(logtalk, [interactive(false), upgrade(true)]).
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
% Pack `logtalk' is already installed @3.30.0
true.
$ rm -rf ~/.local/share/swi-prolog/pack/logtalk rm -rf ~/.local/share/swi-prolog/pack/Downloads/logtalk-*
$ swipl -q
1 ?- pack_install(logtalk, [interactive(false), upgrade(true)]).
pack_install(logtalk, [interactive(false), upgrade(true)]).
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
% "logtalk-3.31.0.tgz" was downloaded 2 times
Package: logtalk
Title: Logtalk - Object-Oriented Logic Programming Language
Installed version: 3.31.0
Author: Paulo Moura <pmoura@logtalk.org>
Maintainer: Paulo Moura <pmoura@logtalk.org>
Packager: Paulo Moura <pmoura@logtalk.org>
Home page: https://logtalk.org/
Download URL: https://logtalk.org/files/swi-prolog/packs/logtalk-3.31.0.tgz
true.
Thanks for reporting. I don’t think it’s an issue in any of the packs. I looked into the pack files for Logtalk and their data seems correct. I would guess the same for the rdet pack. Maybe some issue with the recent changes to pack location?
I had previously removed all the “pack” files from /usr/lib/swi-prolog and had re-installed all my packs (which went into ~/.local/share/swi-prolog/pack).
Note that upgrade works using the wildchart URL in the pack description: it asks for the page after removing the file pattern, expecting an HTML page with links where it gets all links that match the pattern, computes the versions and compares the latest version to the installed.
When I look at the rdet pack page, I see that its URL has changed between github and rlaanemets.com … would that account for the problems with upgrading that package?
The pack.pl file doesn’t provide a download URL pattern as specified in https://www.swi-prolog.org/howto/PackInfo.html. Older version used a git download and this upgrade simply means git pull.
Fixed in the current git version for the Logtalk packs (https://github.com/LogtalkDotOrg/logtalk3/commit/f7e093e4c58520b7c8f0f78b4bb231b10ca9de09).
Still not working (for logtalk 3.30.0 -> 3.31.0):
?- pack_install(logtalk, [upgrade(true)]).
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
% Pack `logtalk' is already installed @3.30.0
true.
?- pack_remove(logtalk).
% Removing '/home/peter/.local/share/swi-prolog/pack/logtalk' and contents
true.
?- pack_install(logtalk, [upgrade(true)]).
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
Install logtalk@3.31.0 from https://logtalk.org/files/swi-prolog/packs/logtalk-3.31.0.tgz Y/n?
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
% "logtalk-3.31.0.tgz" was downloaded 5 times
Package: logtalk
Title: Logtalk - Object-Oriented Logic Programming Language
Installed version: 3.31.0
Author: Paulo Moura <pmoura@logtalk.org>
Maintainer: Paulo Moura <pmoura@logtalk.org>
Packager: Paulo Moura <pmoura@logtalk.org>
Home page: https://logtalk.org/
Download URL: https://logtalk.org/files/swi-prolog/packs/logtalk-3.31.0.tgz
Install "logtalk-3.31.0.tgz" (17,242,461 bytes) Y/n?
true.
The fix I mentioned in in the Logtalk git version. The packs are only created for stable versions. It should work when the next Logtalk stable version (3.32.0) is released (expected in November).
But shouldn’t upgrade(true) always get a new version, regardless of what the current version is? There’s nothing displayed about stable vs non-stable version, as far as I can tell; and nothing I could find in the SWI-Prolog documentation about stable/non-stable.
The bug, as Jan mentioned, is that the existing packs contain a fixed URL for the specific version instead of the URL pattern required for the upgrade to work. My reference to “stable” was about Logtalk stable vs git (i.e. development) versions, not SWI-Prolog. I.e., rephrasing, the packs are only created for Logtalk stable versions.
Do I understand you correctly – that if the URL in the currently installed version of a package isn’t of a particular form, then upgrade won’t work? That seems to be a design bug.
(And it also means that if the package is moved to a different server, then upgrade won’t work.)
That’s my understanding from Jan’s reply, the documentation he mentioned, and from looking into the URLs of other packs.
The pack system was designed to work without a central authority. Using a URL pattern to fetch a new version allows for that. The price is indeed that you cannot migrate to another server. The central database that keep track of packs being downloaded can do so, but after some issues the rules were tightened not to allow registering a new version from a different location as well.
I think the current pack system is a bit too simple. It did prove the need for one and I guess it is time for some redesign …
1 Like
I just tried the upgrade option … nothing happened for logtalk or tap. When I did a pack_remove/1 + pack_install/1, I got the new version.
(I had forgotten about pack_upgrade/1 and I don’t know how to install an older version so that I can try again)
Also, the options don’t seem to be checked for validity – I used update(true) by mistake and there was no complaint.
I don’t know about the upgrade issue. Don’t seem to have any out-of-date packages. You should be able to install an old one by providing the download location explicitly.
By design, SWI-Prolog predicates that process options do not complain about options they do not understand. This largely simplifies writing a new predicate that processes options and calls other predicates that process options we can now simply pass the option list around. Otherwise we have to know which predicates accept which options and filter for each call. It also provides a bit smoother path adding options. Of course, the downside is that if you need to rely on a predicate processing some option and you either mistype or this version of the predicate doesn’t support this option you are in trouble. In other words, you should consider options much like environment variables.
The IDE tools use the predicate_options/3 declarations to highlight unknown options or wrong types. There is also check_predicate_options/0 to warn about option issues. Note that this only works for options that are directly passed to predicates that have an option declaration, i.e., not for dynamically assembled option lists.
Agreed that this make sense; maybe an additional update option with the same meaning would help avoid errors. 
Anyway, here’s a demonstration of pack_install/2 with upgrade not working but pack_upgrade/1 works:
?- pack_info(edcg).
Package: edcg
Title: Extended DCG
Installed version: 0.9.1.6
Installed in directory: /home/peter/.local/share/swi-prolog/pack/edcg
Author: Peter Van Roy <peter.vanroy@uclouvain.be>
Maintainer: Peter Ludemann <peter.ludemann@gmail.com>
Packager: Michael Hendricks <michael@ndrix.org>
Home page: https://github.com/kamahen/edcg
Download URL: https://github.com/kamahen/edcg/archive/*.zip
Provided libraries: edcg
true.
pack_install/2 with upgrade does nothing:
?- pack_install(edcg, [upgrade(true)]).
% Contacting server at https://www.swi-prolog.org/pack/query ... ok
% Pack `edcg' is already installed @0.9.1.6
true.
pack_upgrade/1 works, although it outputs a mysterious error message:
?- pack_upgrade(edcg).
Upgrade "edcg" from 0.9.1.6 to 0.9.1.7 Y/n? y
Verify package status (anonymously)
at "https://www.swi-prolog.org/pack/query" Y/n?
% Contacting server at https://www.swi-prolog.org/pack/query ...
ERROR: Server reported the following error:
ERROR: No permission to register pack(edcg) `'https://api.github.com/repos/kamahen/edcg/zipball/refs/tags/v0.9.1.7''
Package: edcg
Title: Extended DCG
Installed version: 0.9.1.7
Author: Peter Van Roy <peter.vanroy@uclouvain.be>
Maintainer: Peter Ludemann <peter.ludemann@gmail.com>
Packager: Michael Hendricks <michael@ndrix.org>
Home page: https://github.com/kamahen/edcg
Download URL: https://github.com/kamahen/edcg/archive/*.zip
Install "edcg-0.9.1.7" (730,184 bytes) Y/n?
true.
However, despite the error message, the upgrade appears to have worked:
?- pack_info(edcg).
Package: edcg
Title: Extended DCG
Installed version: 0.9.1.7
Installed in directory: /home/peter/.local/share/swi-prolog/pack/edcg
Author: Peter Van Roy <peter.vanroy@uclouvain.be>
Maintainer: Peter Ludemann <peter.ludemann@gmail.com>
Packager: Michael Hendricks <michael@ndrix.org>
Home page: https://github.com/kamahen/edcg
Download URL: https://github.com/kamahen/edcg/archive/*.zip
Provided libraries: edcg
true.