gambit: Re-create as a pip package `pygambit` (help wanted!)
Gambit, the package for computation in game theory, is being actively developed again and has made several releases in 2024. Congratulations to @tturocy for obtaining support from the Alan Turing Institute for the development of this package.
In this PR, we update our use of Gambit to make it compatible with Gambit 16.x via its Python package pygambit.
Steps:
- [x] Package and Feature
- [x] Update imports (first pass: rename
gambit->pygambit) - [x] Sphinx role for linking to new documentation https://gambitproject.readthedocs.io/en/latest/pygambit.user.html
- [ ] Update API use (Help wanted - send PRs)
Cc: @drvinceknight @kcrisman @fchapoton
:memo: Checklist
- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [ ] I have created tests covering the changes.
- [ ] I have updated the documentation and checked the documentation preview.
:hourglass: Dependencies
- #37810
Documentation preview for this PR (built with commit 906a88a0ae8db8fa5ac433b1cb396b44a195f4ed; changes) is ready! :tada: This preview will update shortly after each push to this PR.
Just as a point of order, how does one see which parts of the diff are just from this particular PR and not from (say) #37810?
This is a welcome development, though, I second the congrats to the developer. I don't know if we want to make it a standard package, is this draft currently adding it as optional?
how does one see which parts of the diff are just from this particular PR and not from (say) #37810?
Actually #37810 is not merged here yet. I prepared it after preparing the PR here because it became clear that more work is needed to finish it but I want the removal #37810 done as quickly as possible.
I don't know if we want to make it a standard package, is this draft currently adding it as optional?
Yes, it's adding it as "optional" (see file build/pkgs/pygambit/type). I'd think adding it as a standard package would have to go through sage-devel again.
Many thanks @mkoeppe for initiating this. We've been trying to do work in Gambit on standardising packaging to make it easier for downstream integration (with SageMath high on that list). Please let us know if we can help because, as noted, we're actually resourced now!
The new packaging looks all good, and installing in Sage is already working with the present branch.
On our side just the uses of the old gambit Python API need to be updated to the new pygambit API; but I don't have first-hand experience with either of the two.
The new packaging looks all good, and installing in Sage is already working with the present branch.
On our side just the uses of the old
gambitPython API need to be updated to the newpygambitAPI; but I don't have first-hand experience with either of the two.
With respect to this, we should disclose that we are currently very much in a "move fast and fix things" mode. There will be breaking API improvements across minor versions. For at least this calendar year, we probably won't always be able to provide deprecation warnings (but we will try to do so where we can). To compensate for this our plan is to maintain at least the two previous minor releases (starting from 16.1) with bug fixes, so users won't be forced to adapt their code to API changes simply to get around some bug.
By about this time next year, we will be hoping to have settled into a more mature lifecycle where there'll be fewer API changes and a deprecation path for the ones that do happen.
The new packaging looks all good, and installing in Sage is already working with the present branch.
On our side just the uses of the old
gambitPython API need to be updated to the newpygambitAPI; but I don't have first-hand experience with either of the two.
With respect to this, we should disclose that we are currently very much in a "move fast and fix things" mode. There will be breaking API improvements across minor versions. For at least this calendar year, we probably won't always be able to provide deprecation warnings (but we will try to do so where we can). To compensate for this our plan is to maintain at least the two previous minor releases (starting from 16.1) with bug fixes, so users won't be forced to adapt their code to API changes simply to get around some bug.
By about this time next year, we will be hoping to have settled into a more mature lifecycle where there'll be fewer API changes and a deprecation path for the ones that do happen.
I got to say, will this work like gap or there will be a missing pieces?
Hello @mkoeppe - there's now a fair bit of momentum underway on Gambit around development and documentation. Do you know if this is likely to be picked up in the near future?
There's now a fair bit of momentum underway on Gambit around development and documentation. Do you know if this is likely to be picked up in the near future?
My guess is that, at the current time, this would require at least some Gambit developers to modify this pull request to the most recent head, possibly with some other modifications relative to packages. An email to the sage-devel list might clarify which pieces of this can be used as-is (hopefully most!). I would love to see this return, though I'm not currently in a position to help directly, my apologies.