Sage packages for GAP packages

[Travis Scrimshaw]

Hey all,
   So I am wanting to do implement an interface to the optional GAP package QuaGroup, which will require another optional Sage package. Yet there are also a number of other GAP packages that might be useful to a number of people (e.g., SLA, hecke, liealgdb, all of the various HomAlg pkgs). The questions I have are:

- How many of these should be bundled?
- Do we want to use the usual optional spkgs for each one?
- Are there any special mechanisms we can introduce to make these spkgs easier to maintain on the Sage side?
- What do we want to call these spkgs?
- Do we want to add liealgdb to the database_gap spkg?

Thank you,
Travis

[Francois Bissey]

Not sure how many of these should bundled. Or if they should be bundled at
all.
You can take a gap package and install it in ~/.gap and it will be picked up
(not sure how that translate for windows). So I would only package those
that have a non-trivial install or need an external dependency that we would
also ship.

I cannot really answer the other questions.

François

[Dima Pasechnik]

On Saturday, June 25, 2016 at 5:39:54 AM UTC+1, Travis Scrimshaw wrote:

Hey all,
   So I am wanting to do implement an interface to the optional GAP package QuaGroup, which will require another optional Sage package. Yet there are also a number of other GAP packages that might be useful to a number of people (e.g., SLA, hecke, liealgdb, all of the various HomAlg pkgs). The questions I have are:

- How many of these should be bundled?
- Do we want to use the usual optional spkgs for each one?
- Are there any special mechanisms we can introduce to make these spkgs easier to maintain on the Sage side?
- What do we want to call these spkgs?

It is much easier to add these packages to gap_packages spkg (except various *db things 

that by right should be in database_gap)

All you basically need then is a small change in spkg-src and spkg-install

Only packages with non-0 compiled components are tricky to add sometimes.

[Travis Scrimshaw]

 
I don't have any real qualms about adding QuaGroup to gap_packages as it is just one additional GAP package. However, I'm slightly concerned about adding a bunch of additional GAP packages to it in the long term not to cause bloat and since they are somewhat more specialized.

Not sure how many of these should bundled. Or if they should be bundled at
all.
You can take a gap package and install it in ~/.gap and it will be picked up
(not sure how that translate for windows). So I would only package those
that have a non-trivial install or need an external dependency that we would
also ship.

   I think it would be good to have a simple way to do this. I guess what I am asking is what people think about adding another script, if we should access it as part of sage -i, and if we want to control the versions of the packages that get used.

   The only method I know to add GAP packages is here: https://wiki.sagemath.org/InstallingGapPackages. So at the very least, I would like to see an "official" policy and instructions (i.e., in the main documentation).

Thanks,
Travis

[Dima Pasechnik]

On Sunday, June 26, 2016 at 6:22:46 AM UTC+1, Travis Scrimshaw wrote:

On Saturday, June 25, 2016 at 3:11:44 AM UTC-5, Dima Pasechnik wrote:

On Saturday, June 25, 2016 at 5:39:54 AM UTC+1, Travis Scrimshaw wrote:

Hey all,
   So I am wanting to do implement an interface to the optional GAP package QuaGroup, which will require another optional Sage package. Yet there are also a number of other GAP packages that might be useful to a number of people (e.g., SLA, hecke, liealgdb, all of the various HomAlg pkgs). The questions I have are:

- How many of these should be bundled?
- Do we want to use the usual optional spkgs for each one?
- Are there any special mechanisms we can introduce to make these spkgs easier to maintain on the Sage side?
- What do we want to call these spkgs?

It is much easier to add these packages to gap_packages spkg (except various *db things 

that by right should be in database_gap)

All you basically need then is a small change in spkg-src and spkg-install

Only packages with non-0 compiled components are tricky to add sometimes.

 
I don't have any real qualms about adding QuaGroup to gap_packages as it is just one additional GAP package. However, I'm slightly concerned about adding a bunch of additional GAP packages to it in the long term not to cause bloat and since they are somewhat more specialized.

 

GAP-language only packages are very small, and I don't see a problem having as many as we see fit.

GAP people are complaining about "broken" GAP distributions, as they currently ship all their packages

in the standard GAP install. 

Sometimes adding new GAP packages to Sage leads to finding bugs in GAP, see

e.g. https://github.com/gap-system/gap/issues/775 :-)

Packages with extra code on the other hand may include extra libraries like Flint bundled in, I forgot now which GAP packages have different versions of Flint (or perhaps some other thing, like NTL)   bundled, but this surely happens.

GAP has very loose policy on adding packages, leading to this kind of bloat in particular.

Not sure how many of these should bundled. Or if they should be bundled at
all.
You can take a gap package and install it in ~/.gap and it will be picked up
(not sure how that translate for windows). So I would only package those
that have a non-trivial install or need an external dependency that we would
also ship.

   I think it would be good to have a simple way to do this. I guess what I am asking is what people think about adding another script, if we should access it as part of sage -i, and if we want to control the versions of the packages that get used.
   The only method I know to add GAP packages is here: https://wiki.sagemath.org/InstallingGapPackages. So at the very least, I would like to see an "official" policy and instructions (i.e., in the main documentation).

Hmm... a fool-proof method would involve checking package dependencies, for there may be some, specified in a (rather heavy) GAP's meta-language they have for this purpose; this involves versioning etc --- in fact GAP itself does not have such a tool!

IMHO if you feel like creating such a tool, this should go upstream...

 

Dima

Thanks,
Travis

[Francois Bissey]

> On 26/06/2016, at 17:22, Travis Scrimshaw <tsc...@ucdavis.edu> wrote:
>
> The only method I know to add GAP packages is here: https://wiki.sagemath.org/InstallingGapPackages. So at the very least, I would like to see an "official" policy and instructions (i.e., in the main documentation).

I see. This somewhat mimics the documentation of gap at
http://www.gap-system.org/Manuals/doc/ref/chap76.html#X7B6CD527825945CD
which is to put packages under basically GAPROOT/pkg.
I would call that the beginner method.

This is somewhat under-documenting the capabilities.
In chap 76.2-3 you learn that gap will look for packages
in any “pkg” directories under the directories specified
by the variable
GAPInfo.RootPaths
this variable can be augmented with the command
ExtendRootDirectories
and you could put stuff in an initialisation file to
augment it to whatever you want.
However by default the variable GAPInfo.RootPaths
contains two directories:
fbissey@QCD-nzi3 ~/sandbox/git-fork/sage-7.2 $ ./sage -sh

Starting subshell with Sage environment variables set. Don't forget
to exit when you are done. Beware:
* Do not do anything with other copies of Sage on your system.
* Do not use this for installing Sage packages using "sage -i" or for
running "make" at Sage's root directory. These should be done
outside the Sage shell.

Bypassing shell configuration files...

Note: SAGE_ROOT=/home/fbissey/sandbox/git-fork/sage-7.2
(sage-sh) fbissey@QCD-nzi3:sage-7.2$ gap
┌───────┐ GAP 4.8.3, 19-Mar-2016, build of 2016-05-16 20:23:04 (NZST)
│ GAP │ http://www.gap-system.org
└───────┘ Architecture: x86_64-pc-linux-gnu-gcc-default64
Libs used: gmp, readline
Loading the library and packages ...
Packages: GAPDoc 1.5.1
Try '?help' for help. See also '?copyright' and '?authors'
gap> Print( GAPInfo.RootPaths, "\n");
[ "/home/fbissey/.gap/", "/home/fbissey/sandbox/git-fork/sage-7.2/local/gap/latest/" ]
gap>

As you see ~/.gap is looked first.

Advantages for putting things in ~/.gap/pkg:
1) when gap is upgraded they will still be there, while …/gap/latest/pkg
will point to a new clean install.
2) if you have a global sage install (think SMC and sage-on-gentoo)
and packages like Atlas_rep, you need to install them under
~/.gap/pkg because they want to download and write data locally…
3) It is looked at first, so that’s the place you want to put stuff
to supersede whatever else is installed.


François

[Dima Pasechnik]

There are few GAP packages, one of them io, which need GAP kernel extensions built (which are some kind of shared libraries). I am not sure whether this works with users building GAP extensions for a systemwide GAP install.

Dima

[Travis Scrimshaw]

Thank you both for your answers. I think what I will do for now is add QuaGroup to gap_packages, which I think will be the easiest thing for me to implement the interface I want, and liealgdb to database_gap. I will also add François's instructions to the top-level Sage doc for the trivial to install GAP packages.

Best,
Travis