maint(deps): require mpmath >= 1.1.0, < 1.4.0, Bump version to 1.12.1

[oscarbenjamin]

References to other Issues or PRs

See gh-26273

Brief description of what is fixed or changed

Require 'mpmath >= 1.1.0, < 1.4.0'.

Bump version to 1.12.1 in preparation for release.

Other comments

Release Notes

• other
  • SymPy 1.12.1 adds the version constraint mpmath >= 1.1.0, < 1.4.0.

[sympy-bot]

✅

Hi, I am the SymPy bot. I'm here to help you write a release notes entry. Please read the guide on how to write release notes.

Your release notes are in good order.

Here is what the release notes will look like:

• other
  • SymPy 1.12.1 adds the version constraint mpmath >= 1.1.0, < 1.4.0. (#26413 by @oscarbenjamin)

This will be added to https://github.com/sympy/sympy/wiki/Release-Notes-for-1.12.1.

Click here to see the pull request description that was parsed.

<!-- Your title above should be a short description of what
was changed. Do not include the issue number in the title. -->

#### References to other Issues or PRs
<!-- If this pull request fixes an issue, write "Fixes #NNNN" in that exact
format, e.g. "Fixes #1234" (see
https://tinyurl.com/auto-closing for more information). Also, please
write a comment on that issue linking back to this pull request once it is
open. -->

See gh-26273

#### Brief description of what is fixed or changed

Require 'mpmath >= 1.1.0, < 1.4.0'.

Bump version to 1.12.1 in preparation for release.

#### Other comments


#### Release Notes

<!-- Write the release notes for this release below between the BEGIN and END
statements. The basic format is a bulleted list with the name of the subpackage
and the release note for this PR. For example:

* solvers
  * Added a new solver for logarithmic equations.

* functions
  * Fixed a bug with log of integers. Formerly, `log(-x)` incorrectly gave `-log(x)`.

* physics.units
  * Corrected a semantical error in the conversion between volt and statvolt which
    reported the volt as being larger than the statvolt.

or if no release note(s) should be included use:

NO ENTRY

See https://github.com/sympy/sympy/wiki/Writing-Release-Notes for more
information on how to write release notes. The bot will check your release
notes automatically to see if they are formatted correctly. -->

<!-- BEGIN RELEASE NOTES -->
* other
  * SymPy 1.12.1 adds the version constraint `mpmath >= 1.1.0, < 1.4.0`.
<!-- END RELEASE NOTES -->

[github-actions]

Benchmark results from GitHub Actions

Lower numbers are good, higher numbers are bad. A ratio less than 1
means a speed up and greater than 1 means a slowdown. Green lines
beginning with + are slowdowns (the PR is slower then master or
master is slower than the previous release). Red lines beginning
with - are speedups.

Significantly changed benchmark results (PR vs master)

· Did not find results for commit upstream/master

Significantly changed benchmark results (master vs previous release)

       before           after         ratio
     [41d90958]       [a4429927]
     <sympy-1.11.1^0>                 
-         764±2μs          472±3μs     0.62  solve.TimeSparseSystem.time_linear_eq_to_matrix(10)
-     2.17±0.01ms          872±4μs     0.40  solve.TimeSparseSystem.time_linear_eq_to_matrix(20)
-     4.29±0.03ms         1.28±0ms     0.30  solve.TimeSparseSystem.time_linear_eq_to_matrix(30)

Full benchmark results can be found as artifacts in GitHub Actions
(click on checks at the top of the PR).

[moorepants]

I asked this on the related issue. But if we are releasing a bugfix to make 1.12.1 work with mpmath >1.3 (including this alpha release), then why would we add an upper bound?

[oscarbenjamin]

We need the upper bound so that after mpmath 1.4.0 is released pip install sympy==1.12.1 will select a compatible mpmath version. Currently we are adding changes needed for compatibility with mpmath 1.4.0 alpha 0 but more changes are expected before mpmath 1.4.0 final.

[moorepants]

There is no way to know at this point in time (time of release of 1.12.1) whether a future mpmath will be compatible or not. This is the essential fallacy about upper bound pins. The only time it is appropriate to add an upper bound pin is if you can retroactively add a pin to a prior release after a dependency release breaks it.

If mpmath 1.4.0 releases and breaks 1.12.1, then we should just release 1.12.2 that works with mpmath 1.4.0.

[oscarbenjamin]

There is no way to know at this point in time (time of release of 1.12.1) whether a future mpmath will be compatible or not.

This is precisely why we need to constrain the versions to those that are known to be compatible. Also it is not true that there is no way to know. If you follow mpmath development and study sympy's dependency on mpmath then you will see that it is quite likely that the next version of mpmath will not be compatible with the current version of sympy.

Rather than adding 1.12.2 with tighter version constraints we can instead add 1.12.2 with looser version constraints if that turns out to be possible in future. Each release should have known working version constraints at the time of release though.

Look I have wasted a lot of time on this when I wanted to spend this week releasing sympy 1.13. It is very unhelpful that you jump in at this point with an objection on principle but (AFAICT) no particular understanding of the details of what is going on with mpmath development.

[oscarbenjamin]

Note also that we need this 1.12.1 release out before numpy 2.0 is released:
https://github.com/astral-sh/uv?tab=readme-ov-file#pre-release-handling

[moorepants]

It is very unhelpful that you jump in at this point with an objection on principle but (AFAICT) no particular understanding of the details of what is going on with mpmath development.

I have followed what is going on with mpmath and read all the related issues, in mpmath and pytorch, etc. My objection to an upper bound on mpmath is with full prior knowledge of all of that information and the nuances of the ordeal. I'm guessing that you have probably read this https://iscinumpy.dev/post/bound-version-constraints/, but if you haven't it explains (in great detail) why we shouldn't add upper bound pins. I hope we do not start adding upper bound pins to any of SymPy's dependencies for the reasons stated in that post. We should make any future SymPy releases as compatible with as many existing mpmath releases as possible (even alpha and beta if needed). That is feasible and will not introduce installation incompatibilities if you need mpmath latest in an environment with SymPy 1.12.1, for example.

[oscarbenjamin]

That is feasible and will not introduce installation incompatibilities if you need mpmath latest in an environment with SymPy 1.12.1, for example.

What do you mean by "feasible"?

Have you personally done anything to ensure compatibility between mpmath and sympy?

Are you saying that it is feasible because you are assuming that I will make it work? (No one else has done anything to help with this so far.)

Regardless of who does this how can they possibly make this work? We don't know what future incompatibility they need to handle.

You are taking a dogmatic position here: look at the concrete situation. We already see that mpmath's 1.4.0 alpha 0 release breaks sympy 1.12. It would be absurd to assume a priori that a sympy release now would be compatible with the next mpmath release.

I don't care what the blog post says: we need a version cap on mpmath. If you want to object to that then we can just not release any new sympy versions.

[moorepants]

Hi Oscar, I have clearly made you irritated because you are doing all the work here and I'm bringing an objection. I do have a true and legitimate concern about including upper bound pins in SymPy's dependencies, but I don't see a how we could converse about it if you presume I don't understand what is going on and saying that you don't care what arguments I've pointed to. If the only solution is to upper bound pin mpmath for one bug fix release to give some breathing room around the broader pressure (pytorch, etc), then maybe we do that. But I hope we aren't looking to do this as standard practice. It is not clear if that is happening here or if we will try to remove the pin in 1.12.2.

By "feasible", I mean that releasing new software releases when a new version of a dependency is released is the sustainable fix to managing software with dependencies. A negative is that if mpmath is no longer dormant and does not deprecate changes with a decent time duration, then we are stuck having to release rapidly every time mpmath does. Pinning an upper bound or pinning to an exact version of a dependency prevents that version of SymPy to be installed with future, likely mostly compatible, versions of mpmath. SymPy <1.12 will always be broken if installed with mpmath 1.4. There is nothing we can do about it. But SymPy >=1.12.1 can be made to work with mpmath 1.1.0 to 1.4.0 without restricting the ability to install SymPy 1.12.1 with mpmath > 1.4.

[sympy-bot]

🚨🚨🚨ERROR🚨🚨🚨 There was an error automatically updating the release notes. Normally it should not have been possible to merge this pull request. You might want to open an issue about this at https://github.com/sympy/sympy-bot/issues.

In the meantime, you will need to update the release notes on the wiki manually.

The error message was: Not all changelog entries were added. Make sure there is a header called ## Authors at the end of the release notes.