The gap_pkg from oscar-system

Deal with cyclic dependency between `alnuth` and `polycyclic`

One plan is to just drop one of them and require the user to always depend on both of them

How to map versions

For the JLLs (GAP_pkg_*_jll) the pattern is to map GAP version 1.2.3 to 100.200.300, plus potentially an offset. This decouples the GAP version from the Julia version a bit and gives us room to update the wrapper packages even if the underlying GAP packages have not changed.

should we adopt a similar scheme for the wrappers here in this repository?
how to deal with package versions like 2021.04-03 (used by Homalg and CAP these days)?
in the past, some packages had versions like 1.0c. I don't think that is the case for anything right now, but perhaps the GAP side should start to impose tighter constraints on version patterns?
GAP packages don't follow semver, so we may need to take that into account, too..

Add more JLLs for packages that may need them

The following distributed GAP packages seem to either have a kernel extension, or ship some binaries that need to be compiled. In either case, having a JLL would be nice.

For packages which use an external binary, we also need a way to allow the GAP code to interact with these binaries; that may require interposing wrapper scripts, possibly using https://github.com/oscar-system/BinaryWrappers.jl

Add a (Julia) script which can "import" more GAP packages, and also apply updates

This script (or a function it provides) would take a path to a GAP package directory, extract data from its PackageInfo.g, and use that to either create a corresponding GAP_pkg_FOOBAR.jl, or update an existing such .jl package to match the package version.

Some thought needs to be put into how this would deal with those GAP packages that need a kernel extension or other binary executable, and thus need a JLL; for now I think it would suffice to add an optional flag argument that allows saying "this needs a JLL"; plus perhaps a list of package names for which we hardcode that needs_jll=true holds.

Then we could use this script to import the whole package distribution, and also do that whenever the distribution is updated. Of course also non-distributed GAP packages could be treated like that.

Deal with libstdc++ issues in ferret and other C++ using libs

Right now I am getting this:

julia> using GAP_pkg_ferret

julia> GAP_pkg_ferret.load()
#W dlopen() error: dlopen(/Users/mhorn/.julia/artifacts/49b1930968bd5aa85f37a4c6770a3a524bba6db7/lib/gap/ferret.so, 5): Symbol not found: __ZdlPvm
  Referenced from: /Users/mhorn/.julia/artifacts/49b1930968bd5aa85f37a4c6770a3a524bba6db7/lib/gap/ferret.so
  Expected in: /usr/lib/libstdc++.6.dylib
 in /Users/mhorn/.julia/artifacts/49b1930968bd5aa85f37a4c6770a3a524bba6db7/lib/gap/ferret.so
ERROR: Error thrown by GAP: Error, module '/Users/mhorn/.julia/artifacts/49b1930968bd5aa85f37a4c6770a3a524bba6db7/lib/gap/ferret.so' not found in
  LOAD_DYN( filename ) at /Users/mhorn/.julia/artifacts/1ae5d8f1898d9dcbe8dc3d93f56369c864a8e717/share/gap/lib/files.gd:578 called from
<function "LoadDynamicModule">( <arguments> )
 called from read-eval loop at /Users/mhorn/.julia/gaproot/v4.12/pkg/ferret-1.0.6/read.g:15

Need to figure out how to resolve this, and how to adjust generate_wrapper.jl so that it inserts it into any wrapper package like GAP_pkg_ferret that needs it

Map GAP dependencies to Julia dependencies?

There is some deactivated code for doing this already in generate_wrapper.jl.

The idea is that e.g. GAP_pkg_cvec should depend on ``GAP_pkg_io(and dousing GAP_pkg_io`) because `cvec` depends on `io`. With that in place, it will suffice to do this to load cvec into Julia:

using GAP_pkg_cvec ; GAP_pkg_cvec.load()

But there are a bunch of questions:

figure out a way to get the UUID of e.g. GAP_pkg_io when it is not yet in the (resp. "a") registry
- perhaps just parse the GAP_pkg_*/Project.toml files and extract the UUID from there?
how to map version restrictions in GAP's PackageInfo. to compat strings
...

Add CI tests

Make `GAP_pkg_FOOBAR/test/runttests.jl` files do something useful

Naively we could simply invoke GAP.Globals.TestPackage("FOOBAR"). However, in the current model that exits GAP (and hence OSCAR / Julia), which we don't want...

In the short term, we could hack TestDirectory to handle exitGAP := true differently... But most GAP packages call FORCE_QUIT_GAP(1); after their TestDirectory call...

Short term solution: temporarily replace the GAP functions QuitGap (called by TestDirectory) and FORCE_QUIT_GAP with our own, which just record the exit code set by GAP, i.e., GapExitCode(), to determine the test outcome

We could add a helper function doing all that to GAP.jl. It ain't pretty, but it should work for the majority of packages

Long term:

get GAP packages to drop those FORCE_QUIT_GAP calls
add a dedicated (and documented) interface in GAP to indicate the test result
modify TestDirectory to use that, and/or add a sanctioned way to override the exitGAP option... and/or add a better named alternative to exitGAP (however, most GAP packages will want to stay compatible with older GAP versions, switching to such a new option would be a hassle for them)

The generated READMEs should describe how to load one of the packages. I.e.
```
julia> using GAP_pkg_foobar ; GAP_pkg_foobar.load() 
```
They should also point back at this repository here.
they should point out the license, and that it may differ from that of the GAP packages
in fact perhaps mention the GAP package license, at least by quoting the pkginfo.License field, if present (in which case it contains an SPDX ID)
...

Other information that should be included?

`browse` specific changes

GAP_pkg_browse should set up terminfo paths, see oscar-system/Oscar.jl#1891 -- once that is done and we once we use it, we can remove the corresponding from Oscar.jl and from GAP.jl

oscar-system / gap_pkg Goto Github PK

gap_pkg's People

Contributors

Watchers

gap_pkg's Issues

Recommend Projects

Recommend Topics

Recommend Org