temporarily force numpy<2, drop support for Python 3.13+ #408
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #408 +/- ##
=======================================
Coverage 81.08% 81.08%
=======================================
Files 28 28
Lines 7888 7888
Branches 1464 1464
=======================================
Hits 6396 6396
Misses 1026 1026
Partials 466 466 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@viseshrp @margalva -- could you elaborate on the reasons you have to block numpy<2? We are having a lot of troubles already at the metapackage level because PyDynamicReporting can't support 2.x starting on 3.10. The rest of the teams have adapted their codebases to support it accordingly. We need to understand what is the problem here and how we can avoid this limitation since the fact that you are preventing the installation of numpy 2.x affects all the PyAnsys ecosystem libraries in the long run - i.e. it blocks us all from moving forward when installing our PyAnsys libraries together. |
|
Pinging @ansys/pyansys-core and other teams involved in the discussion (@da1910 @Andy-Grigg) |
|
@RobPasMue pydynamicreporting is used by the core of EnSight, Fluent and AEDT. At least EnSight and Fluent, use Ansys python from the common files in the unified installer (I'm unsure by AEDT). That python distribution uses numpy 1.23.5. Having a higher version of numpy in pydynamicreporting would force an update on the version of numpy for the flagships as well, breaking them. As long as the ansys common python relies on numpy 1.23.5, pydynamicreporting cannot update its numpy version. |
|
@RobPasMue Yes, as Marina mentioned, it is because of the numpy version built by the commonfiles Python folks. Upgrading in pydynamicreporting will break when a user uses the new numpy to push data over to the EnSight/ADR installation, which depend on commonfiles Python and uses numpy<2. We have received a few bug reports with respect to that, so we have no choice but to revert. |
|
@RobPasMue @margalva I am closing this PR for now until we find a better solution, as it is also breaking our builds for 3.13. While using Python 3.13+ in pydynamicreporting (which only supports numpy>2), the user will not be able to render certain types of data in ADR. @margalva Should we drop support for Python3.13 until this is fixed? |
|
@RobPasMue @ansys/pyansys-core Just fyi, the good news is - DevOps folks are working on building numpy 2 for ADR which will allow us to upgrade it in pydynamicreporting as well. There is no timeline yet though. |
viseshrp
changed the title
viseshrp
changed the title
|
Hi @viseshrp @margalva - first of all, thank you both for your explanations. Much appreciated! Based on the outcome of this PR, and starting on 0.10.3, we will have to remove PyDynamicReporting from the metapackage whenever the user requests to install it in Python 3.13. This will look in our pyproject.toml as follows: dependencies=[
...
"ansys-dynamic-reporting==0.10.3; python_version<'3.13',
...
]This is a temporary skip, since an explicit requirement on our side is supporting Python 3.13. Important If by the time a new metapackage release is required you still don't support Python 3.13 we will have to effectively remove you from the metapackage at large - in order to avoid delivering mixed environments wrt our own libraries (i.e. Python 3.11 containing N PyAnsys libraries, Python 3.13 containing M PyAnsys libraries -- we should always be delivering the same amount of our own libraries). Once support for NumPy 2.x has been re-established and Python 3.13 please let us know so that we can remove this constraint from the metapackage. |
No description provided.