Better handling of package metadata that changes after pickup & GAP release

[wilfwilson]

Currently, the all of the data shown about a package on the GAP website relates to the version included with the latest release of GAP. When releases of GAP and/or a package are infrequent, and badly timed in relation to each other, and when package updates are not picked up and accepted for a little while, the result can be that the included version of a package is somewhat old. (That's meant as a statement, not as a complaint directed at anyone.)

In particular, if the URLs related to a package's website change (especially its homepage, or its development repository), then this will not be reflected on the GAP website until:

1. a new release of the package is made;
2. that release is picked up and accepted for redistribution;
3. a new GAP release is made.

This means that the GAP website could have broken links for a long time.

This currently affects DeepThought and Semigroups, and it affected the Digraphs package for several months until GAP 4.11.1 was released. There are possibly others. (I've had several reports of the broken links on the Semigroups page in recent weeks.)

I wonder what we can do about this? And moreover, how can we do it in a robust, timely, and ideally automated way?

I realise that it's a potentially complicated issue. And it might require the website to be integrated somewhat with the 'package update system'.

It is partially complicated by the fact that the PackageInfo.g file contains information that is very much specific to that version of the package (e.g. the release date; authors), but also information that is more general about the package as a whole (e.g. development repository URL).

In my ideal world, the GAP website would display the version-specific data of the former type, but the most recent data of the latter type. It would be nice if it could look in the distributed PackageInfo.g file for certain information, but then consult the PackageInfo.g file at the URL of the PackageInfoURL field of the distributed PackageInfo.g to get the more up-to-date other information. But of course if that URL changes in the mean time, then this won't work.

Or a script could be run every day in GitHub Actions that looks (again, where?) for updated/moved packages, and updates the relevant information on the website correspondingly.

These are just some ideas and musing; thoughts welcome. For now, I'll update some things manually, but not that these changes would currently be overwritten the next time the gap-system/gap update-website.py script is run.

[wilfwilson]

These issues are all at least tangentially related: #15, #147, #201.

[wilfwilson]

This website now contains package information for each GAP release (since 4.11.0) in the _data/package-infos folder; this consists of the (renamed) package-infos.json files that are now auto-generated for each release.

Currently, the newly updated GAP dev/releases/update-website.py script gets the package-infos.json file for any new release that it comes across, and it does not subsequently overwrite any such package-infos.json file. Therefore, for example, this gives us the freedom to make edits to the package-infos.json file of the latest GAP version to update the URL of a package whose website has changed since the package version that's included in the latest GAP release.

In particular, I have edited the _data/package-infos/4-11-1.json file to have the latest DeepThought and Semigroups URLs.

I do, however, continue to hold the views above: the data for displaying individual package pages should probably be separate from the data about the packages included in any particular release.