On Tue, 2 Jul 2024 at 17:29, Aaron Meurer <asmeu...@gmail.com> wrote:
>
> 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.
I was imagining doing that but just running the whole sympy test
suite. It takes about 15 minutes to run the whole not slow test suite
with pytest's parallel tests in Github Actions like:
import sympy; sympy.test(parallel=True)
It recently became worth using parallel tests in Github because the
number of cores was increased from 2 to 4 in the standard runners
which is why I removed the splits from CI.
For the python-flint CI it takes about 25 minutes just to build the
Windows wheels before the Windows tests can even begin so you would
hardly notice a job running the sympy test suite.
--
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/CAHVvXxQSkkw__%3DMQ3HoZnmn9ojkVqh3Vvp6Ja_vnx-ZUwX7kHA%40mail.gmail.com.
