gh-115119: removed implicit fallback to the bundled libmpdec #134078
Conversation
|
On top of configure changes in #133997. N/B: all linux jobs, except for changed (not sure if it worth) - have no system libmpdec. For MacOS we run tests with system libmpdec. |
configure.ac
Outdated
| [AC_MSG_WARN([m4_normalize([ | ||
| no system libmpdecimal found; falling back to bundled libmpdecimal | ||
| (deprecated and scheduled for removal in Python 3.15)])]) | ||
| USE_BUNDLED_LIBMPDEC()]) | ||
| no system libmpdecimal found; falling back to pure-Python version | ||
| for the decimal module])]) | ||
| AS_VAR_SET([py_cv_module_]_decimal, [n/a])]) |
There was a problem hiding this comment.
AC_MSG_ERROR? I think opting in to the pure Python version should be explicit.
There was a problem hiding this comment.
AC_MSG_ERROR ?
Well, that could be an option.
Though, more complex wrt implementation: all linux jobs will fail, unless we either provide system libmpdec or change ./configure invocations to use a new option.
I think opting in to the pure Python version should be explicit.
I'm not sure it's useful. After all, the pure-Python version is always available as the _pydecimal.py.
Did you suggest a new option like --with-purepython-decimal?
There was a problem hiding this comment.
A warning is actually ok, but users may not see it and then, they would have a slow version of decimal. OTOH, an error might be too abrupt but at least the tansition would be more explicit and would force people to upgrade if they want an efficient way to do it.
I'm +0.25 for AC_MSG_ERROR just to force people to update. We can add an option --allow-fallback-to-pydecimal to handle CI possible failures, though this means that devs should be aware that their C code might not be tested in the CI due to that.
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
| @@ -1,4 +1,8 @@ | |||
| #!/bin/sh | |||
|
|
|||
| # Workaround missing on ubuntu 24.04 libmpdec-dev | |||
| sudo add-apt-repository ppa:ondrej/php | |||
There was a problem hiding this comment.
Would it be useful to backport this change to 3.13 and 3.14 branches? Which libmpdec is used on these branches? The vendored copy or the system library? If it makes sense to backport, I would suggest to extract these changes (.github/workflows/posix-deps-apt.sh) into a separated PR.
There was a problem hiding this comment.
Would it be useful to backport this change to 3.13 and 3.14 branches? Which libmpdec is used on these branches?
Most jobs runs on ubuntu-24.04. That means they use bundled copy, which is v2.5.1. Though, the difference wrt the latest v4.0.1 is not as big as suggest version numbers.
If it makes sense to backport, I would suggest to extract these changes (.github/workflows/posix-deps-apt.sh) into a separated PR.
I'm not sure if it does. One argument for this is that we build with the system libmpdec on MacOS jobs (quick check shows here v4.0.1), while use bundled copy on Linux jobs - thus, testing all configure options. Not sure it's a strong point.
Co-authored-by: Victor Stinner <vstinner@python.org>
libmpdecsources #115119📚 Documentation preview 📚: https://cpython-previews--134078.org.readthedocs.build/