On Tue, Jul 2, 2024 at 5:09 AM Oscar Benjamin <oscar.j.benja...@gmail.com> wrote: > > On Mon, 1 Jul 2024 at 18:04, Aaron Meurer <asmeu...@gmail.com> wrote: > > > > On Mon, Jul 1, 2024 at 4:38 AM Oscar Benjamin > > <oscar.j.benja...@gmail.com> wrote: > > > > > > I think my preference is: > > > > > > 1. Use python-flint >= 0.6.0, < 1.0 automatically. > > > 2. Don't use python-flint < 0.5.0 or >= 1.0 and don't give any warning > > > about it. > > > 3. Unless the SYMPY_GROUND_TYPES=flint variable is set in which case > > > use python-flint regardless of the version. > > > 4. Keep future versions of python-flint compatible with SymPy 1.13 > > > until python-flint 1.0. > > > 5. Once SymPy 1.13 is released add a job in python-flint CI to test > > > against SymPy 1.13. > > > > > > Does anyone have any views on this? > > > > I guess the most ideal would be if we could synchronize with the > > upstream and have them promise that any release with a breaking change > > would bump, say, the major version number. That we we could pin <1.0 > > and be sure that will be the right thing. > > > > Also presumably if an issue does arise we can release a patch release > > that adds a pin, so maybe it isn't a huge deal as long as we are able > > to stay on top of it. > > It can be hard to say sometimes what exactly is a "breaking change" vs > a bug fix. Ultimately if sympy depends on some behaviour of > python-flint then we won't know if a change causes problems without at > least running the test suite somewhere. It is unreasonable though for > python-flint to promise that all future releases will be fully tested > against all future releases of sympy in perpetuity.
How well can you isolate the parts of the SymPy test suite that exercise flint. If it's straightforward to do that and those tests run quickly, then you could easily have a job that runs them for SymPy (latest release - 1, latest release, master) on the python-flint CI. Aaron Meurer > > The way that numpy and scipy do it is that they guarantee some range > so scipy is compatible with numpy 2.n to 2.n+2 which I think can also > work here. > > If sympy uses python-flint 0.n to say 0.n+3 then python-flint can test > older versions of sympy for as long as they are "supported" and sympy > can just not use newer versions. Then we can say that sympy now > accepts 0.6.0-0.9.0 and python-flint can test against sympy 1.13 until > version 0.10.0. > > I don't want to go back and make point releases for old sympy versions > for this kind of thing if possible. There are all kinds of other > things like new numpy versions, new Python versions etc that break old > releases of sympy. Backporting fixes for all of those opens a whole > bunch of questions about how long "support" is supposed to last for > old releases. Maybe that is where SPEC 0 comes in but SPEC 0 is time > based and neither sympy nor python-flint have regular release > schedules. > > -- > Oscar > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sympy+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sympy/CAHVvXxTRyUfZWpCPqKJ6ARW25Q5dXZ0qST8mQKE0ObUiVYL0Nw%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6%2BmoG2G9croTLYHu%3D0nvcZ8DA97%3Das5_CDVHdCqpRf%3DLQ%40mail.gmail.com.
