GAP should not require PrimgGrp/SmallGrp/TransGrp packages
The libraries of small, primitive and transitive groups which previously were an integral part of GAP were split into three separate packages:
For backwards compatibility, these are required packages in GAP 4.9 (i.e., GAP will not start without them). We plan to change this for GAP 4.10, once all packages which currently implicitly rely on these new packages had time to add explicit dependencies on them.
This issue under the milestone 4.10 is created to track this:
- list all packages that need to be updated
- notify package authors
- track progress
Started work on this via #2589, but I am pretty sure tons of packages need changes...
E.g. lots of packages use smallgrp in their test files. This can be resolved by adding an explicit LoadPackage("smallgrp") to their tst/testall.g file.
Just to get a first rough approximation of which packages might be affected, I did some very simple grepping to get a first approximation of the issue (note that will be both false positives and false negatives with this method):
Packages which seem to use TransitiveGroup:
- [ ] ctbllib
- [ ] hap
- [ ] loops
- [ ] radiroot
- [x] SCSCP -- no issue
- [ ] simpcomp -- see https://github.com/simpcomp-team/simpcomp/pull/57
- [x] transgrp -- no issue
Packages which seem to use PrimitiveGroup:
- [ ] Browse
- [ ] ctbllib
- [x] digraphs --
PrimitiveGrouponly appears in comments - [ ] genss -- see https://github.com/gap-packages/genss/pull/20
- [x] grape -- resolved in version 4.9.3 -- see https://github.com/gap-packages/grape/pull/51
- [x] primgrp -- no issue
- [ ] recog
- [x] SCSCP -- no issue
- [ ] simpcomp -- see https://github.com/simpcomp-team/simpcomp/pull/57
Packages which seem to use SmallGroup:
- [x] anupq -- resolved in version 3.3.2
- [ ] autpgrp
- [ ] crime
- [ ] crisp
- [ ] ctbllib
- [x] cubefree -- resolved in version 1.21 -- see https://github.com/gap-packages/cubefree/pull/11 (SmallGrp is now a dependency)
- [ ] format
- [ ] groupoids
- [ ] grpconst
- [ ] hap
- [ ] help
- [ ] irredsol
- [ ] laguna
- [ ] loops
- [ ] modisom
- [ ] permut
- [ ] polenta
- [ ] polycyclic
- [ ] rcwa
- [ ] rds
- [x] SCSCP -- handled in SCSCP 2.4.4
- [x] semigroups -- resolved in version 5.5.4
- [ ] sglppow
- [ ] simpcomp -- see https://github.com/simpcomp-team/simpcomp/pull/57
- [x] SmallGrp -- no issue
- [ ] smallsemi
- [ ] unitlib
- [ ] utils
- [ ] wedderga
- [ ] xgap
- [ ] XMod
- [ ] XModAlg
We could now go through these packages, and update the above check lists once we know the package either declares suitable dependencies, or has been fixed, or was never really affected in the first place (ideally leave a comment stating which it was)
All in all, this is a big bunch of packages, so we'd need a good plan on how to approach this if we want to resolve it in time for GAP 4.10... May need to punt this to a later release otherwise.
This won't be in 4.10; not even sure that it realistically can be in 4.11, but I bumped it to that milestone anyway.
Removed this from the 4.11 milestone. I don't think we can do this in time, and in fact, I am not sure it'll ever happen, it just isn't worth the effort compared to many other more pressing issues.
That said, if anybody wants to help with this: pick one (or multiple!) of the packages on the list above; check whether it really needs any of the functionality of PrimgGrp/SmallGrp/TransGrp ; if no, state so here (and check its checkbox); if yes, provide a pull request to that package which adds the dependency to that package's PackageInfo.g, then add a comment here with a link to that PR. Rinse and repeat for more packages :-)
I should also point out that the GAP library itself uses these packages, e.g.
primgrp: used inlib/gpprmsya.gito compute normalizers, maximal subgroups, ... in alternating&symmetric groupssmallgrp: lots of code in the library usesIdGrouptransgrp: e.g.lib/galois.giusesTransitiveGroup
Erm... should this ever happen at all?
We discussed about this at length today during GAP Days Summer 2025, and there was a lot of interest in making this happen, e.g. by @james-d-mitchell
I'd be open to look into this again. The obvious first thing to do would be to make all those implicit dependencies on those packages explicit. I am not so sure how up-to-date the lists are. One way to handle this would be to use a variant of the GAP Package Distro CI, where we just modify it to run GAP with --bare, and then see what breaks, and fix it as we go.
For transgrp it seems the only GAP library code relying on it is the Galois groups code. Perhaps that code should be in a package itself?
Or perhaps we should revise the policy on disallowing LoadPackage in library code...?
Some thoughts on this:
- Running
teststandard.gwithout these packages might give a decent indication on where GAP relies on them?
gap --bare -c 'LoadPackage("GAPDOC");' tst/teststandard.g
- If a package uses
SmallGroupin their tests, but the tests are not (overly) reliant on properties/attributes precalculated by SmallGrp, perhaps the groups in question can simply be constructed usingPcGroupCode(for PcGroups) or a (small/minimal) generating set (for PermGroups)? Then SmallGrp might not have to be loaded at all.
@stertooy yes we (@james-d-mitchell and me) discussed things along these lines, and James has started work on this.
First off, https://github.com/gap-system/PackageDistro/pull/1183 shows which packages run into errors in their tests suite if GAPDoc is the only package loaded initially.
If a package only uses smallgrps in its tests, then e.g. calls to SmallGroup can be replaced by other group constructors -- e.g. for anupq we could replace some by calls to DihedralGroup and similar. Some else are indeed using PcGroupCode, as you also suggested.
But I expect some package test suites will not be ameanable for this (e.g. because they use IdGroup). In that case my proposed solution is to insert LoadPackage("smallgrps"); at the start of tst/testall.g (or similar files).
That leaves packages that actually use smallgrp in their library code, those will have to get it as a dependency.
Of course similar approaches should be taken for transgrp and primgrp.
Just to clarify the aim of this issue:
- We want that GAP runs without PrimGrp/SmallGrp/TransGrp (perhaps slower than with these packages), thus the library code has to be changed in some places.
- We want that the GAP tests run without these packages.
- Is it o.k. if examples in the Tutorial and in the Reference Manual use the three packages? I would be in favour of that, we should just explicitly load them in the beginning, such that the examples get tested in the right context.
- For GAP packages that are using PrimGrp/SmallGrp/TransGrp, these three packages either must be declared as needed packages, or code and tests must be changed such that the three packages may be missing. (In the case of CTblLib, changing the code accordingly is challenging, and will increase the number of package extensions.)
What about the library of perfect groups? Currently this is not a package, but it would fit into the pattern.