Don't build IO

[stertooy]

We've already stopped building IO a few times, but had to revert it every time (see e.g. 1bd4673).

With the release of build-pkg@v3, building IO (if needed) should become the responsability of that action. This can be done by adding IO either to the Dependencies.TestPackages component in PackageInfo.g, or to the extra-pkgs input of the action.

(Making this a draft PR for now since I'm not sure if we want to merge this right away)

[fingolfin]

In principle I'm fine with it, but isn't it a breaking change (based on everything we've learnt)? It might be borderline OK to include into v3 if we first make sure everything uses build-pkg@v3 ?

[stertooy]

A breaking change might indeed be the better option, to avoid previously passing workflows suddenly failing.

[fingolfin]

I note that there are still 78 package using gap-actions/build-pkg@v2, and just 15 using v3 -- and 54 are still on v1, I think those are all using setup-gap@v2.

Also, setup-gap@v2 is still used by about 62 packages.

But I am tempted to upgrade all the build-pkg@v2 to v3, and see what happens; if any are broken, we can revert it there (the harder part might be to find out which are broken and which are not...

[fingolfin]

I've switched all GAP packages that were using build-pkg@v2 to v3. Had to revert a few that were still using setup-gap@v2; but I think everything (in the gap-packages org, plus Digraphs + Semigroups) which is using setup-gap@v3 is now also using build-pkg@v3.

In the meantime, I think the io package has some trouble because we are building an older io version without its consent.

I guess I want to say: I'd be fine with merging this now, and dealing with the potential fallout later.

[stertooy]

What's the plan after merging this? Do we keep this in v3 or do we bump to v4?

[fingolfin]

If one considers this a breaking change, then the proper way to handle this would be to make it v4.

Alas, that would require again touching 100s of CI workflows, producing lots of churn, for no good reason.

But actually, I consider this removal of a temporary workaround; the initial v3 did not build IO either, we added it as a stop gap because we discovered several broken packages that then affected other "innocent" packages.

So my plan would be to put this into v3. If it breaks any packages, so be it. I'll have an eye on https://gap-packages.github.io/status (which already reports a bunch of "broken" packages, but those are mostly for unmaintained / unpublished packages). Then soon I might apply a mass patch again to switch packages to test against just GAP "versions" devel/latest/minimal ; that'll then reveal if we broke anything.