lmfit / lmfit-py

Non-Linear Least Squares Minimization, with flexible Parameter settings, based on scipy.optimize, and with many additional classes and methods for curve fitting.
https://lmfit.github.io/lmfit-py/
Other
1.06k stars 274 forks source link

Numpy2 fixes #959

Closed newville closed 2 months ago

newville commented 3 months ago

Description

This fixes a few problems with NumPy 2.

It fixes #958 by explicitly removing a few odd non-serializable functions if using NumPy2 and a version of asteval that still includes those. That is, this is really a problem with asteval exporting numpy functions that it shouldn't (and are deprecated and not really needed anyway). But, until that is fixed in asteval (in progress), and that version of asteval is required, it is probably safest to look for and remove those offending functions,

This adds packaging as a dependency in order to compare versions.

This also updates the "latest" variations of the tests to use "numpy>=2.0"

This does not alter the test labeled "development version", but that might be slightly dated.

Type of Changes
Tested on

Python: 3.12.4 | packaged by conda-forge | (main, Jun 17 2024, 10:11:10) [Clang 16.0.6 ]

lmfit: 1.3.1.post1+geee021f6.d20240629, scipy: 1.14.0, numpy: 2.0.0, asteval: 0.9.33, uncertainties: 3.2.1

Verification

Have you

codecov[bot] commented 3 months ago

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 93.20%. Comparing base (7710da6) to head (0f23b10).

Additional details and impacted files ```diff @@ Coverage Diff @@ ## master #959 +/- ## ========================================== - Coverage 93.20% 93.20% -0.01% ========================================== Files 10 10 Lines 3767 3765 -2 ========================================== - Hits 3511 3509 -2 Misses 256 256 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

reneeotten commented 3 months ago

so with the new release of asteval, we can just drop almost all of this and require version 1.0.0 instead?

newville commented 3 months ago

@reneeotten We could do that. I had been thinking that we should wait for a version or so before requiring "most recent asteval", just in case some packaging systems are not as aggressive at updating packages. But I could be persuaded.

We could merge this, release a Numpy2-compatible version, and then immediately raise an Issue to clean this up ;)

I'll do whichever of those you prefer. a) pin to asteval >= 1.0 and remove most of the changes here b) keep asteval >= 0.9.28, merge this, and give 6 to 9 months before requiring asteval > 1.

FWIW, I decided to tag "asteval 1.0" after years of being stable and then adding in more flexibility for namespaces a year ago. That release "worked" in the sense that within days I was contacted by a group at one of those well-known tech companies that had found some security flaws. I hope to clear those up and push 'asteval 1.0.1' in a week or two.

That's mostly unrelated, but maybe an additional reason to keep lmfit tied to "very recent asteval".

reneeotten commented 2 months ago

In my opinion we should just require the latest "asteval" and remove all the changes here that are then bot required anymore. Downstream packagers can easily update asteval to the latest version, it has no dependencies and build very quickly.

newville commented 2 months ago

@reneeotten OK, requiring asteval>=1.0 does make this all a lot simpler. I would suggest Squash-and-Merge with a modified message, or I could close this and open a new PR with a single commit.

reneeotten commented 2 months ago

okay, let me take a look later today and I'll squash-merge or do some git voodoo to clean it up.

reneeotten commented 2 months ago

@newville I clean-up the commits a bit, added the dependency version changes to the documentation and CI, and folded in two more small changes for the latest SciPy/NumPy versions and pre-commit hooks.

newville commented 2 months ago

@reneeotten Thanks for cleaning that up and for the maintenance fixes too. I'll merge (not squash) this. I think this warrants releasing version 1.3.2. I'll try to get to that later today or within a few days.

newville commented 2 months ago

@reneeotten ... except that I am also going to try to fix #960 before 1.3.2 -- but that should be too much of a delay.