Unvendor libmpdec sources
#115119
Comments
+1 for an autoconf warning. |
|
Adding an external libmpdec to the macOS installer build shouldn't be a big issue. Assign it to me if you proceed with this. |
|
FTR: the source deps repo is now updated. |
|
@ned-deily: for build-installer.py, is there more to do than adding a configuration for mpdecimal? I've used the following |
|
Likely yes, I'll take care of it. Thanks. |
|
I took a quick look at this and be aware that this change proposal will likely impact everyone building Python 3.13 on macOS. macOS does not ship a copy of libmpdec so, if the bundled version is removed, anyone building Python on macOS will now need to provide a local copy, either building from source or using a version from one of the widely-used third-party package managers, like Homebrew or MacPorts. Both currently have |
Last time I checked, libmpdec did not provide pkgconfig files: $ ls $(brew --prefix libmpdec)/lib/pkgconfig
ls: /opt/homebrew/opt/mpdecimal/lib/pkgconfig: No such file or directory
$ cd mpdecimal-2.5.1; find . | grep pkg
$ |
|
With the current 4.0.0 version, it appears both Homebrew and MacPorts ship them: $ pkg-config libmpdec --cflags
-I/opt/homebrew/Cellar/mpdecimal/4.0.0/include
$ pkg-config libmpdec --libs
-L/opt/homebrew/Cellar/mpdecimal/4.0.0/lib -lmpdec -lm
...
$ pkg-config libmpdec --libs
-L/opt/macports/lib -lmpdec -lm |
|
Yes, the 4.0.0 version does indeed provide pkg-config configuration files. I'll work on an Autoconf patch. |
Only libmpdec 4.0.0 supports pkg-config.
This includes adding what should be a relatively temporary `Modules/_decimal/windows/mpdecimal.h` shim to choose between `mpdecimal32vc.h` or `mpdecimal64vc.h` based on which of `CONFIG_64` or `CONFIG_32` is defined.
…-115182) This includes adding what should be a relatively temporary `Modules/_decimal/windows/mpdecimal.h` shim to choose between `mpdecimal32vc.h` or `mpdecimal64vc.h` based on which of `CONFIG_64` or `CONFIG_32` is defined.
…-115182) This includes adding what should be a relatively temporary `Modules/_decimal/windows/mpdecimal.h` shim to choose between `mpdecimal32vc.h` or `mpdecimal64vc.h` based on which of `CONFIG_64` or `CONFIG_32` is defined.
…-115182) This includes adding what should be a relatively temporary `Modules/_decimal/windows/mpdecimal.h` shim to choose between `mpdecimal32vc.h` or `mpdecimal64vc.h` based on which of `CONFIG_64` or `CONFIG_32` is defined.
pkg-config is supported for libmpdec 4.0.0 and newer.
|
@zware are we still aiming for 3.13 for the first batch of items? |
Resolved by: |
|
I missed the |
|
I don't think you can do here something. Once the CPython will not bundle libmpdec - we will have no choice but fallback to the Someone must do real job and package back the libmpdec for Debian. |
|
Hmm.. I'll have to look into it more. I'll was expecting to have to Obviously this is not ideal, but until us Debian users get some traction on that issue, that's probably the best I can hope for. When I get some spare time I'll test out a build with the vendored code nuked and see if the overrides work like I expect. |
Ah, yes - that will work. |
|
What would be the guidance for folks building embedded distributions this case? Use relevant CFLAGS to relatively link to a copy of libmpdec shipped with the embedded distribution? |
Ondřej Surý has stepped up to reinstate and maintain mpdecimal in Debian: |
That's great! Thanks for the update. |
|
@zware, it seems we are out of scheduled process in the 3.14 - as fallback to the bundled copy is still here. Shall we remove that in beta? Or we can skip this and just remove the mpdecimal copy in 3.15, together with the configure.ac fallback? BTW, it seems the mpdecimal is in the Debian again. Probably there are no good reasons to not follow to schedule in 3.15. CC @erlend-aasland |
Yes, as you would do with any of the other third party dependencies. My gut reaction would be to simply postpone everything with one release. That is, do in 3.15 what was planned for 3.14. |
|
CC @hugovk, is this too late for 3.14 to remove fallback to bundled copy? This wasn't announced in 3.13, but removal of bundled copy in 3.15 - was. Sorry for asking, just to be sure. Will you also suggest to shift planned stuff by one release? |
|
I've not read through the ~90 comments here, but seems this is not a bugfix and there's no pressing need for this in 3.14, so I suggest we do as @erlend-aasland said:
Devguide reminder:
|
The evil plan is right in the description.
I'm in doubts, but rather "yes".
Ok, then I'll prepare a documentation patch for 3.13/14 and remove fallback in 3.15. |
|
@skirpichev I'm a little confused, we shouldn't change anything in 3.14 at this point, but the 3.15 development cycle is open. Do you intend to change anything in Python 3.15 relating to the vendored libmpdec? I've no objections to delaying the removal of the vendored sources to 3.16, I'd just like to understand the rationale. A |
The puzzle is the plan (see description) to:
Only 2) was announced and doing 1) seems now impossible for the 3.14. So, we have options:
Our bundled copy is 2.5.1 vs 4.0.1 latest. But I don't see big changes. So, probably removing is not urgent and we should prefer b), as suggested above. I prefer a), for the record. |
|
Ok, pr's are ready for review:
|
We advertised the following to users:
We didn't mention removing the implicit fallback, so personally I think it's OK to remove both in one go. Ubuntu 26.04 (to be released c. 1 month before Python 3.15b1) will have However, removing the fallback in 3.15 and then removing the bundled sources in 3.16 is the more conservative position. A |
This will be not immediately available in gh action runners.
I think more core devs in the thread are for that option, thus I withdraw my pr with removal of the bundled copy. Or should we ask someone else? |
Hi! We build CPython releases for all supported Ubuntu LTS versions (so currently 22.04 + 24.04, and next year 26.04 too). By the time of Python 3.16's release, Ubunu 22.04 LTS should be out of standard support, so we won't have to support that. However, that still leaves 24.04 that from the sounds of it won't have an |
To facilitate cleaner updates of the externally-maintained
libmpdecrequired by the_decimalmodule, we should migrate away from the bundled copy inModules/_decimal/libmpdecand towards an "external" incpython-source-depsfor Windows and--with-system-libmpdecby default elsewhere.My tentative plan is as follows:
mpdecimal-2.5.1andmpdecimal-4.0.0tocpython-source-deps:mpdecimal-2.5.1external (gh-115119: Switch Windows build to mpdecimal external #115182)mpdecimal-4.0.0Post#118539: amend Ubuntu CI to use system installed mpdecimallibmpdecsources #115119 (comment)--without-system-libmpdec(with warning)--with[out]-system-libmpdecconfigureoptions andModules/_decimal/libmpdec/Linked PRs
The text was updated successfully, but these errors were encountered: