Addin sympy to SPEC 0?

[Anton Akhmerov]

Hi all,

There is now SPEC 0, a SciPy-community-wide standard for versions of different packages that developers should aim supporting, see https://scientific-python.org/specs/spec-0000/

I believe Sympy is the biggest package missing from SPEC 0, and I've asked the maintainers of SPEC 0 what is the best way to proceed (https://discuss.scientific-python.org/t/spec-0-include-sympy/975?u=akhmerov). They appear to welcome the idea and recommended to reach out via this mailing list.

So here's the question I'd like to know (as someone authoring software that depends on Sympy): would Sympy like to join SPEC 0?

Thank you for your consideration,

Anton

[Oscar Benjamin]

Hi Anton,

What difference does it make to you in practice whether or not SymPy
is listed in SPEC 0?

SymPy does not really support old versions with maintenance releases
so it does not really have a "support cycle" in the sense that SPEC 0
seems to describe. There can be a bugfix release shortly after a
feature release to fix some obvious regressions but that is basically
it.

SymPy itself broadly tries to have wide version support for other
packages like numpy just because without listing them as hard
dependencies there is no way to indicate which versions sympy is
compatible with. There is no way to put version constraints on
optional dependencies in pip/PyPI land.

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+un...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e21d2db6-8ac4-4b01-a92c-7e49eb591146n%40googlegroups.com.

[Anton Akhmerov]

Hi Oscar,

I want to be able to answer a question: "which versions of SymPy should I try to support within my package that has SymPy as a dependency". It doesn't make a big difference whether this question is answered by SPEC 0 or by SymPy itself, except for SPEC 0 being a central point of reference. I realized that SymPy has no support cycle, but I think the question is still useful regardless.

Anton

[Oscar Benjamin]

Hi Anton,

To be clear I am not against adding SymPy to SPEC 0. I just want to
understand what this means in practice. Presumably if SymPy is added
there then people will have some expectation that it means something
somehow.

I don't really know how to answer the question "which versions of

SymPy should I try to support within my package that has SymPy as a

dependency" because I am not sure what the benefit would be of
supporting more than 1 version of SymPy.

Is there a reason that someone would need to combine a newer version
of your package with an older version of SymPy?

Oscar

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/abcea775-f3aa-45c0-883e-ceec9482cc6cn%40googlegroups.com.

[Jason Moore]

A reason to depend on and be compatible with more than 1 version of SymPy would be to maximize compatibility when installing your package (and thus SymPy) alongside a collection of interdependent packages.

Jason

moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRk_ZZmbXig0fTJ3rQ_dn0Ecu4FfO_Nv9qG%3Dzd9Jy8AWg%40mail.gmail.com.

[Anton Akhmerov]

> Is there a reason that someone would need to combine a newer version
of your package with an older version of SymPy?

I believe it's pretty much what Jason wrote: a yet another package might not support the latest SymPy yet, and a standard similar to SPEC 0 is a suggestion of what SymPy maintainers consider reasonable.

[Aaron Meurer]

On Sun, Mar 10, 2024 at 8:48 AM Oscar Benjamin
<oscar.j....@gmail.com> wrote:
>
> Hi Anton,
>
> What difference does it make to you in practice whether or not SymPy
> is listed in SPEC 0?
>
> SymPy does not really support old versions with maintenance releases
> so it does not really have a "support cycle" in the sense that SPEC 0
> seems to describe. There can be a bugfix release shortly after a
> feature release to fix some obvious regressions but that is basically
> it.

This fact alone would be worth notating in that document. It's not
always obvious to what degree different packages support older
versions.

Aaron Meurer

>
> SymPy itself broadly tries to have wide version support for other
> packages like numpy just because without listing them as hard
> dependencies there is no way to indicate which versions sympy is
> compatible with. There is no way to put version constraints on
> optional dependencies in pip/PyPI land.
>
> Oscar
>
> On Sun, 10 Mar 2024 at 14:24, Anton Akhmerov <anton.a...@gmail.com> wrote:
> >
> > Hi all,
> >
> > There is now SPEC 0, a SciPy-community-wide standard for versions of different packages that developers should aim supporting, see https://scientific-python.org/specs/spec-0000/
> >
> > I believe Sympy is the biggest package missing from SPEC 0, and I've asked the maintainers of SPEC 0 what is the best way to proceed (https://discuss.scientific-python.org/t/spec-0-include-sympy/975?u=akhmerov). They appear to welcome the idea and recommended to reach out via this mailing list.
> >
> > So here's the question I'd like to know (as someone authoring software that depends on Sympy): would Sympy like to join SPEC 0?
> >
> > Thank you for your consideration,
> > Anton
> >
> > --
> > 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+un...@googlegroups.com.
> > To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/e21d2db6-8ac4-4b01-a92c-7e49eb591146n%40googlegroups.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+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxS%2Bh1foa1G3dfKA58Osp%3D%3DZ9W69gjRygjzphkcstqTarw%40mail.gmail.com.

[Anton Akhmerov]

> SymPy does not really support old versions with maintenance releases
> so it does not really have a "support cycle" in the sense that SPEC 0
> seems to describe. There can be a bugfix release shortly after a
> feature release to fix some obvious regressions but that is basically
> it.

This fact alone would be worth notating in that document. It's not
always obvious to what degree different packages support older
versions.

I have reread the text of SPEC 0, and I believe it means "support cycle" differently from what seems to be Oscar's interpretation. Adopting SPEC 0 does not mean "SymPy developers provide support for vX.Y until AAAA-BB-CC". Rather the meaning of SPEC 0 is "SymPy developers recommend that packages that depend on SymPy should aim to support vX.Y until AAAA-BB-CC". In other words SPEC 0 does not represent additional commitments, but rather it describes how rapidly the code evolves. I believe it is useful for coordinating dependency versions of other packages in the ecosystem.

Does this remark clarify the usefulness of adding SymPy to SPEC 0?

Anton

[Oscar Benjamin]

On Sun, 14 Apr 2024 at 14:15, Anton Akhmerov <anton.a...@gmail.com> wrote:
>
> > SymPy does not really support old versions with maintenance releases
> > so it does not really have a "support cycle" in the sense that SPEC 0
> > seems to describe. There can be a bugfix release shortly after a
> > feature release to fix some obvious regressions but that is basically
> > it.
>
>
>
> This fact alone would be worth notating in that document. It's not
> always obvious to what degree different packages support older
> versions.
>
>
> I have reread the text of SPEC 0, and I believe it means "support cycle" differently from what seems to be Oscar's interpretation. Adopting SPEC 0 does not mean "SymPy developers provide support for vX.Y until AAAA-BB-CC". Rather the meaning of SPEC 0 is "SymPy developers recommend that packages that depend on SymPy should aim to support vX.Y until AAAA-BB-CC". In other words SPEC 0 does not represent additional commitments, but rather it describes how rapidly the code evolves. I believe it is useful for coordinating dependency versions of other packages in the ecosystem.
>
> Does this remark clarify the usefulness of adding SymPy to SPEC 0?

Yes it does. After reading this numpy discussion thread I think I have
a better idea why this matters:
https://mail.python.org/archives/list/numpy-di...@python.org/thread/AHTATJKGUEOILBNUI5IGGZPXJ5FXIRAU/

Basically the problem is that if SymPy puts out new releases for say
Python 3.8 then that potentially means that other libraries that
depend on SymPy have to put out updates for Python 3.8 as well. This
means that even if it is easy for SymPy to support a wide range of
Python versions it might still cause problems for downstream
dependencies. Those downstream dependencies are sort of obliged to
support the same versions as SymPy at least to the extent of being
able to put out an update that caps the SymPy version or something.

Currently SymPy 1.13 is about to ship which is tested with CPython
3.8, 3.9, 3.10, 3.11, 3.12 and 3.13 prereleases. The release files
have
python >=3.8
which means that they will be picked up for install on Python 3.8 or
any newer version of Python. Following SPEC 0 would mean dropping
Python 3.8 and 3.9 immediately now and changing it to
python >=3.10

The last time we discussed dropping support for a particular Python
version was whether to drop 3.8 which many other projects have dropped
support for. It was Matthias Koeppe from Sage who suggested that it
was useful to support Python 3.8. There have been discussions in the
Sage org about following NEP 29 which is basically the same thing:

https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/Ap_1pHlsBQAJ?utm_medium=email&utm_source=footer

Personally I am in favour of going with SPEC 0 in coordination with
the rest of the scientific Python ecosystem. I don't want to cause any
immediate problems for Sage though so I would be reluctant to make a
last minute decision to drop two Python versions right now for 1.13.

--
Oscar

[Oscar Benjamin]

On Tue, 4 Jun 2024 at 21:10, Oscar Benjamin <oscar.j....@gmail.com> wrote:
>
> Personally I am in favour of going with SPEC 0 in coordination with
> the rest of the scientific Python ecosystem. I don't want to cause any
> immediate problems for Sage though so I would be reluctant to make a
> last minute decision to drop two Python versions right now for 1.13.

I followed this up on the Sage mailing list:
https://groups.google.com/g/sage-devel/c/0BPkiiWYrIU/m/9c2asTEaEwAJ?utm_medium=email&utm_source=footer

That suggests that Sage has no need for SymPy 1.13 to support Python
3.8 which would have been dropped 18 months ago if following SPEC 0.
It also suggests that after 1.13 is released it would be fine from
Sage's perspective for SymPy to drop support for both 3.8 and 3.9 but
perhaps not drop 3.10 according to the SPEC 0 schedule (which would be
in a few months time so SymPy 1.14).

--
Oscar

[Anton Akhmerov]

Thank you Oscar for taking action. Does that mean that sympy can endorse spec-0? Or that will it do so starting from some version?

Anton

[Oscar Benjamin]

Hi Anton,

I was hoping that others might express their opinions about this.

SPEC 0 seems fine to me.

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+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/be468354-70b2-4f2b-8269-e0a8fbeaaeb8n%40googlegroups.com.

[Jason Moore]

Dear all,

This seems like an appropriate topic for a SYMPEP.

Jason

moorepants.info
+01 530-601-9791

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxT_9hX4QZi2Xa-D0HygFY%3DSKmBY4-heLuOzuNya00Bj9g%40mail.gmail.com.