deps: Update minimal for sympy and numpy #2605
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2605 +/- ##
==========================================
+ Coverage 91.91% 91.92% +0.01%
==========================================
Files 245 245
Lines 48427 48432 +5
Branches 4255 4256 +1
==========================================
+ Hits 44513 44523 +10
+ Misses 3237 3233 -4
+ Partials 677 676 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
mloubout
force-pushed
the
sympy-compate
branch
11 times, most recently
from
e0fee5c to
a68fe24
Compare
mloubout
changed the title
| pip>=9.0.1 | ||
| numpy>1.16,<2.3 | ||
| sympy>=1.9,<1.14 | ||
| numpy>=2,<2.2.6 |
There was a problem hiding this comment.
Why the max numpy downgrade?
There was a problem hiding this comment.
It's not a downgrade. numpy is currently at 2.2.5 and making minor releases so the dependabot is not catching those because they always satisfy the current major release bound. It's just refining it
There was a problem hiding this comment.
Are there any systems that we know about where Devito is running and numpy is a system dependency (ie: air-gapped systems) where this might cause an issue?
There was a problem hiding this comment.
I think Colab was yes, but I think they updated recently. Handling the sympy-numpy versions is quite a pain if we allow numpy <2 but will see if can find a way.
| return vmin, vmax | ||
|
|
||
|
|
||
| def numpy_compat(required): |
There was a problem hiding this comment.
Note: Ok so basically this was not doing anything because pip runs the build in isolation so sympy is never found and it always default to the PkgNotFound case.
JDBetteridge
left a comment
JDBetteridge
left a comment
There was a problem hiding this comment.
Given that most of the logic is stripped out of setup.py should we start thinking about migrating to a more modern Python packaging solution, namely a pyproject.toml?
mloubout
force-pushed
the
sympy-compate
branch
2 times, most recently
from
d9fd68a to
21522ab
Compare
FabioLuporini
left a comment
FabioLuporini
left a comment
There was a problem hiding this comment.
Minor comments, otherwise GTG
| assumptions = newobj._assumptions.copy() | ||
| for key in ('real', 'imaginary', 'complex'): | ||
| assumptions.pop(key, None) | ||
| newobj._assumptions = assumptions |
There was a problem hiding this comment.
aren't these four lines equivalent to just
newobj._assumptions = {k: v for k, v in newobj._assumptions.items()
if k not in ('real', 'imaginary', 'complex')}
There was a problem hiding this comment.
_assumptions is some fnacy sympy internal type not a plain dict so this would break a lot of stuff.
| sympy.polys.rings._ring_cache.clear() | ||
| sympy.polys.fields._field_cache.clear() | ||
| except AttributeError: | ||
| # SymPy 1.14 and later |
There was a problem hiding this comment.
since I'm paranoid, could you try a git grep _cache in SymPy 1.14 to be sure they haven't added any other random caches?
4 participants
No description provided.