Use the system GAP #36792

These two variables are best combined into one, GAP_ROOT_PATHS. This is how they're used anyway: to reference the locations where GAP packages might be found. Moreover, GAP is willing to report its own root paths, but doesn't make the further distinction between the lib and share dirs. Using the combined GAP_ROOT_PATHS will make it easier to integrate with the system GAP.

When initializing libgap, we use "-l" to specify a list of root paths. In the past we constructed this list manually from the two variables GAP_LIB_DIR and GAP_SHARE_DIR. Now we pass in GAP_ROOT_PATHS directly.

Instead of searching only GAP_LIB_DIR for GAP packages, we now search all entries in GAP_ROOT_PATHS.

These two variables were concatenated into a string that is eventually hashed. Now, the GAP_ROOT_PATHS variable serves a similar purpose; in a normal sage install it will already contain the concatenation of those two variables. So let's hash that instead.

This variable whose counterpart exists in sage.env already will be set by Sage's ./configure script to an appropriate value.

This hides the "user" path for GAP packages. We don't do it for libgap, and I don't think it makes much sense to hide the user's own packages if we're going to use his system GAP, so let's stop.

To support a system GAP installation, we now prepend Sage's old GAP_LIB_DIR and GAP_SHARE_DIR directories to the configured list of GAP_ROOT_PATHS. This will allow GAP packages to be found and used from any of the system or Sage locations.

If we're using the system GAP, we still want sage's CLI gap command to be able to find any GAP packages that were installed via SPKG. The appropriate SAGE_LOCAL search paths are prepended to GAP_ROOT_PATHS already, but we need to tell GAP about them by passing the list to -l.

From the GAP documentation: By default, some needed and suggested GAP packages are loaded, if present, into the GAP session when it starts. This option disables (actually toggles) the loading of suggested packages, which can be useful for debugging or testing. The needed packages (and their needed packages, and so on) are loaded in any case. With the possible exception of PolyCyclic, Sage doesn't need any of those suggested packages, but GAP complains loudly if they're missing. Passing "-A" to the GAP command eliminates those warnings and allows us to pare down our GAP installation, or to use a more minimal GAP from the system.

From the GAP documentation: By default, some needed and suggested GAP packages are loaded, if present, into the GAP session when it starts. This option disables (actually toggles) the loading of suggested packages, which can be useful for debugging or testing. The needed packages (and their needed packages, and so on) are loaded in any case. With the possible exception of PolyCyclic, Sage doesn't need any of those suggested packages, but GAP complains loudly if they're missing. Initializing libgap with "-A" eliminates those warnings and allows us to pare down our GAP installation, or to use a more minimal GAP from the system.

Now that we're passing "-A" to the GAP command, the PolyCyclic package won't be loaded even if it is installed. We do want to use it if it's available, though, so we call LoadPackage explicitly in sage.g.

Now that we're initalizing libgap with "-A", the PolyCyclic package won't be loaded even if it is installed. We do want to use it if it's available, though, so we call LoadPackage explicitly in sage.gaprc to load it. This spews some informational messages if PolyCyclic is NOT installed, but we can hide them by temporarily changing the InfoWarning level.

There's a long list of "recommended" packages that we install for GAP because, otherwise, GAP complains about them being missing when you start it. This can be avoided with the -A flag, however, that we are now passing to both the CLI gap and libgap. These additional packages are therefore no longer needed to silence the warnings. Here we move all of these recommended packages from the gap SPKG to the gap_packages SPKG.

The presence of a GAP package is (at least) trinary: it can be installed and loaded, installed and unloaded, or uninstalled. Here we change the feature test to return "not present" for a package that is installed but not yet loaded.

These can be loaded at runtime with, for example, sage: libgap.LoadPackage("PolyCyclic") And if that ever happens, a cached "not present" will be wrong.

Several doctests in this module require the GAP package PolyCyclic. We add "# optional - gap_package_polycyclic" to them.

Several doctests in these two modules require the GAP package PolyCyclic. We add "# optional - gap_package_polycyclic" to them.

…onal tags Several doctests in this module require the GAP package PolyCyclic. We add "# optional - gap_package_polycyclic" to them.

Instead of atlasrep and tomlib, let's use primgrp and smallgrp in this doctest for test_packages(). The latter are guaranteed to be installed and loaded, making the output predictable.

Several doctests in this module require the GAP package PolyCyclic. We add "# optional - gap_package_polycyclic" to them.

There's a test for unhide() in this module that assumes the PolyCyclic GAP package will always be installed. That may not be the case when now that we support using the system GAP. We update the text of the example and add two "# optional" tags, one of which is needed to hide the feature in the first place.

Several doctests in this module require the GAP package PolyCyclic. We add "# optional - gap_package_polycyclic" to them.

For some reason, GAP can decide to return a different set generators for one of the subgroups in our socle() example. The group is the same, however, so to fix the failing test, we modify it use an equality check rather than the usual string comparison.

This tells GAP not to try to load a bunch of packages that aren't part of the default install, thereby avoiding a bunch of warnings. The gap interface and libgap within sage both already do this.

The order in which DihedralGroup(8).normal_subgroups() is listed is apparently not fixed. To guard against order-based doctest failures, we sort the normal subgroups before printing them.

We have a GAP test in this document that prints (directly via GAP) the normal subgroups of DihedralGroup(10). But apparently, the order in which they are printed is not fixed. We add SortedList() to the NormalSubgroups() call to ensure that the list is always printed in the same order.

Otherwise, when there are duplicates, we list every package twice (or more) in all_installed_packages().

One of our examples for MathonPseudocyclicStronglyRegularGraph() constructs a matrix from a normal subgroup of the graph's automorphism group. The normal_subgroups() method goes through GAP, and GAP's NormalSubgroups() function has some freedom to choose representatives. This leads to the entries of the matrix being unpredictable -- it still satisfies the desired properties, however. To avoid doctest failues due to this unpredictability, we no longer print the entries of the matrix. The rest of the example is fine.

Be nice and mention to users that only the PolyCyclic package (because Sage needs it) will be autoloaded.

Installing gap_packages now means that they are loadable, not necessarily that they are loaded. We add two libgap.LoadPackage calls to ensure that these optional gap_packages tests pass.

This more closely resembles what sdh_configure() is doing.

The example commands in this file are doctested, so they need "optional" tags and the expected output to pass.

Instead of leaving GAP_ROOT_PATHS blank for the gap SPKG, we now use '${prefix}' placeholders to essentially add the old GAP_LIB_DIR and GAP_SHARE_DIR to the list.

Replace the string '${prefix}' with SAGE_LOCAL in GAP_ROOT_PATHS. The spkg-configure.m4 for GAP now uses this as a placeholder.

We used to prepend two sage-specific paths to GAP_ROOT_PATHS here, but we now handle that in gap's spkg-configure so that the value we get from sage-conf is what we use.

It's just a better name for the command that runs a GAP command.

The motivation for deduplicating GAP_ROOT_PATHS still stands, but the old comment about the sage-conf semantics is out-of-date. Rewrite it.

Upon review it was agreed that the gap SPKG should not aim for a minimal installation. We bring the current list of autoloaded packages back into the gap SPKG from gap_packages. (The list is a little shorter now than when it was written.)

Bring the sage list of (attempted) autoloads to parity with the default GAP list.

Mention that we're checking for only the bare minimum set of packages needed for the sage test suite to pass.

Reorganize the GAP variables in sage.env, and then move the _gap_cmd processing out of sage.env and into sage.interfaces.gap where some other gap command processing already takes place.

The doctest for the normal_subgroups() of DihedralGroup(8) cannot simply list them all, because it turns out that in GAP the NormalSubgroups() function has some freedom to choose representatives. As a result, verbatim output is not guaranteed. We are already sorting the subgroups as part of an earlier attempt to solve this problem, so the two trivial subgroups should live at the beginning and end of the list. As such, we use "..." to match whatever is output for the intermediate groups. We also add a new test for the number of normal subgroups. This fixes a test failure on Conda.

Our doctest for as_permutation_group() checks that algorithm="smaller" produces a group that is different from the one obtained with algorithm=None. But this need not be the case (and sometimes it is not): the SmallerDegreePermutationRepresentation() function in GAP is doing its best, but it "might involve the use of random elements and the permutation representation (or even the degree of the representation) is not guaranteed to be the same for different calls." Bottom line, we can't count on the "smaller" group actually being smaller than, or even different from, what we would get without algorithm="smaller". So we drop that test, and compare the degrees of the two groups instead, allowing for equality. This fixes a failing test on Gentoo and Conda.

It's possible for the gap CLI to be installed but libgap to be unusable, for example on systems where libgap-devel is a separate package. We need libgap, so now we test for it.

Change the one "checking the" message to match all of the "checking for" messages.

While testing for a GAP package, we now try to load the package first. Without this, testing of optional GAP packages would not be possible: most "extra" GAP packages are not loaded automatically, so if the feature test didn't load them, they would remain unloaded (and hence unavailable) during test runs. This new behavior also allows us to cache these feature tests again.

Now that polycyclic and a few other packages have been moved back into the core gap SPKG, the description of gap_packages is nonsensical. No gap_packages are loaded automatically in Sage. Let's just say that.

Otherwise it displays the big, ugly, fully-qualified name.

When the system GAP is installed and the SPKG gap is not, the extra gap_packages need to know where to find sysinfo.gap. We can execute a "gap -c ..." command for this.

Based on, * https://packages.fedoraproject.org/pkgs/gap/ * https://build.opensuse.org/package/show/science/gap

With only libgap-dev, we are missing the "gap" executable.

We added this for the CI to try, and it didn't work.

Without this, when certain tests fail, we print a bunch of junk to the screen (and to config.log).

The GAP subpackages listed at, https://packages.fedoraproject.org/pkgs/gap/ are not included with the superpackage install, so we have to list the ones that we use explicitly.

…SPKG If the user doesn't want to use either the sage package manager or his system's package manager, then this should be available immediately.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use the system GAP #36792

Use the system GAP #36792

Commits on Dec 15, 2023