On Mon, Feb 4, 2019 at 2:23 AM Simon King <simon.k...@uni-jena.de> wrote: > > Is the plan to make > > "gap" and alias of (or a wrapper for) "libgap" in future releases? > > I think this would be a good idea in the long run, however would require > a deprecation period. After all, libgap is not a drop-in replacement of > gap, and I talk from experience (authoring the p_group_cohomology spkg) > when I say that the transition from gap to libgap isn't trivial (but is > a good idea).
That is my plan but it will be tricky. Currently users expect gap(...) to run in the pexpect interface (although that's also an implementation detail that might be opaque to many users). So I think the best plan is this: 1) All code in Sage that uses GAP must first be ported over to the libgap interface. This is mostly straightforward but may be non-trivial in some areas. Now the next part is tricky to handle well. Here's one idea, though it's debatable: 2) Add a deprecation message in calls to gap(...) that it will soon use libgap, and users should switch to that. 3) Eventually make gap() an alias for libgap(); at this point the old pexpect interface will be available and deprecated, but not removed. 4) Eventually remove old pexpect interface as well, after a deprecation period. 5) Maybe actually do away with libgap() and keep just gap(). Why have both, at that point? I think this last part is maybe the most contentious, but would also be a long way off if at all. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
