pack_upgrade/1 broken for Github versions

[wouterbeek]

trafficstars

pack_upgrade/1 currently fails for Packs that are hosted on Github and that use version URLs [1] according to current pack documentation.

This may be due to an API change in Github: the Wildcards that are used to match version-denoting URLs [1] do not seem to match the URLs that Github is currently using to denote versions, which are of the form [2]. Changing the value of the download/1 property in the pack.pl file to match [2] fixes the issue.

[1] https://github.com/<owner>/<pack>/releases/*.zip
[2] https://github.com/<owner>/<pack>/releases/tag/*.zip

Only changing the definition in pack.pl is not enough though: pack_upgrade/1 searches the direct parent of the Wildcard URL [2] for links to available versions. It does not use the Github API for this but tries to scrape the HTML page. Unfortunately, [3] does not exist (404 status code).

[3] https://github.com/<owner>/<pack>/releases/tag/

[fnogatz]

This is still a problem for calls of the form pack_install('https://github.com/<owner>/<pack>/archive/<version>.zip') as mentioned in the documentation. For example:

?- pack_install('https://github.com/jonakalkus/xsd/archive/v0.1.2.zip').
ERROR: Version mismatch: pack.pl: 0.1.2, file claims version 0.1.2.2
false.

I tracked down the issue to the point that github_version/4 creates a VersionURI which does not end with .zip (maybe because GitHub's API does not provide a file extension) and therefore the available_download_versions/2 returns a wrong download link without the .zip at the end. As this URL is used by file_name_extension/3, it takes the last digit of the version as the filename extension and raises an error because of mismatching version numbers.

This seems to be a minor bug in @wouterbeek's new approach of using GitHub's API, isn't it? I am using latest SWI-Prolog 7.5.10.

[wouterbeek]

My 'fix' indeed appears to have been incorrect, but the previous situation in which the HTML was scraped for the download link (IIRC then that was actually what was done) also no longer worked( (possibly because Github changed the structure of its HTML). We need to properly fix this by using the official Github API.

[JanWielemaker]

Pushed b8ad01c1abcd9da8699f10f44cc237f73643a3d9, which should fix at least some of this. Wouter's code to query the API to find versions was already in place. This fix avoids interpreting a final digit as a proper file name extension at a higher level, but also avoids interpreting a fully specified URL as a wildcart for which we need to find available versions. As a result a full path will be installed literally (as it should) and anything that starts with https://github.com/<owner>/<repo>/ and contains some wildchart character (* or ?) in the remainder queries the github API