I am building unofficial macOS packages for personal use. My main build machine is running macOS Monterey 12.1 and Xcode 13.2.1. I recently attempted to build Python 3.8.12 as a package using build-installer.py. This worked fine after a bit of dependency wrangling (mostly, downloading the right Tcl/Tk source files manually) and produced an installer package and DMG as expected.

However, it is apparently impossible to actually sign the package. I receive the following error:

% productsign --sign 'Apple Development: ...' /private/tmp/_py/installer/Python.mpkg /private/tmp/_py/installer/Python-signed.mpkg
productsign: preparing "Python.mpkg" for signing ...
productsign: error: component package "PythonFramework-3.8.pkg" uses legacy installer features that make it impossible to sign.

Unfortunately, searching for "legacy installer features" yields zero useful hits, which is a bit of a surprise. I assume that this error message was added to a recent macOS/Xcode build, but I am unable to downgrade easily.

I believe this is probably being triggered because the way the packages are put together differs from the way pkgbuild/productbuild would do it. The longer term solution would probably be to switch to those tools instead of assembling the packages by hand.

Issue reproduces with Python 3.11a4 sources as well, so I'm tagging it as applying for 3.8~3.11.

I noticed that the official installer seems to be built using an entirely different process, as it produces a single-file .pkg in xar format with an embedded Distribution file, rather than an .mpkg directory.

Is there documentation on how these packages are generated? It seems like the scripts for that aren't in the Python source tree?

Apple builds python on their own, so probably you wont have any luck finding the build scripts

The short answer to the original issue: at the moment, build-installer.py continues to create python.org installers in the legacy bundle installer format that is no longer supported by more modern versions of macOS and there are additional steps that are used to convert the artifacts produced by build-installer.py into a modern flat-package (.pkg) format installer. Those steps are outlined in Mac/BuildScript/README.rst but the exact commands are not provided there. The longer answer is that we have long provided macOS installers that are designed to work on a very wide range of macOS versions and Mac hardware. Up until very recently, the production of an installer required multiple steps on different versions of macOS to be able to meet those requirements, i.e. the build of Python itself had to run on an older system (macOS 10.9) but the flat package and signing has to run on a more recent system to be able to be notarized by Apple. And that manufacturing has evolved over many years as Apple has attempted to enhance macOS security while minimizing the impact on end users (e.g. Gatekeeper, code signing, notarization). As of fairly recently (Python 3.10.1 et al) with the addition to Python of full "weaklinking" support on macOS (along with Apple Silicon and Big Sur support), it is now possible to build on a current system while supporting older systems as well as we now do in the new universal2 installer variant. Since we are still providing the legacy 10.9 Intel-only installer variant for 3.9.x releases, there hasn't been an urgent need to modify the overall manufacturing process yet, but I do plan to do so and document prior to the upcoming 3.11 feature code cutoff (in part to better support Apple Silicon Macs).