ネッド・ディーリー氏は、macOSとリリースに関する専門家であり、Python言語サミットで15年間で初めてこの話題について議論したと述べています。

CPythonがリリースを行う際、主な成果物はソースコードの配布物であり、tarballやZIPアーカイブです。その後、各プラットフォームのパッケージング担当者がこれらのソースコードからビルドを行います。しかし、過去にはCPythonは、WindowsとmacOS向けに、あらかじめコンパイルされたインストーラーを提供していました。これは、これらの2つのプラットフォームが他のほとんどのプラットフォームとは「異なる」ためです。

ネッド氏が抱えていた疑問は、過去に行われてきたように、macOSのインストーラーを今後も提供する価値があるかどうかでした。「macOSは大きく進化しており」、Windowsとは「奇妙さの点」で比較できなくなっています。ネッド氏は、この継続の決定は主に「自動運転」によるものであり、macOSのインストーラーは「ごく一部の人しか関わっていない、暗い場所に置かれている」ものであり、また、特定の期間、「私だけがこの機能を維持していた」と認めました。

ネッド氏は、Pythonが「macOSのインストーラーを提供し続ける」べきかどうかを明らかにしたいと考えていました。もしそうであれば、「macOSインストーラーに関する知識をより前面に押し出す」べきであり、macOSプラットフォームに影響を与える変更について、他のPythonのコア開発者に知っておくべき情報を伝えるべきです。「macOSで起こる多くのことは、iOSにも当てはまります」とネッド氏は続けました。「現在、私たちはiOS向けのコンパイル済みのバイナリも提供しています」。

macOSの何が違うのか？

macOSには、Unixのビルドと同様の「静的」と「共有」のタイプ、そしてmacOSとiOSに特有の「フレームワーク」という3つの異なるビルドタイプがあります。フレームワークは、NeXTSTEPで生まれ、Mac OS Xに引き継がれ、システムインターフェースやAPIに使用されています。macOSは、ARM64やx86-64など、複数のプロセッサタイプをサポートするオブジェクトを、単一のファイルにまとめてビルドすることができます。これは、Nedが「fatファイル」と呼んでいます。Appleの開発者ツール（ADT）は、異なるアーキテクチャのファイルを透過的にビルドおよびリンクするためのサポートを提供しており、これを行うためのClangのバージョンも含まれています。iOS、watchOS、およびtvOSも同じADTを使用するため、これらのプラットフォームもこのマルチアーキテクチャのサポートの恩恵を受けることができます。

Appleのソフトウェア開発キット（SDK）ファイル（ヘッダーファイルや共有ライブラリなど）は、通常の場所（/usrなど）にはインストールされず、SDK内に保存されています。これにより、単一の環境変数を使用して、異なるSDKのバージョンを切り替えることができ、単一のmacOSシステム上で、あらゆるAppleのプラットフォーム向けのビルドが可能になります（例えば、macOS上でiOS向けのビルドを行う、またはApple Silicon上でIntel x86-64 macOS向けのビルドを行うなど）。

Nedは、Pythonのフレームワークビルドにより、PythonをmacOSのアプリケーションに直接組み込むことができ、「外部依存関係なしで、どこでも動作する」アプリケーションを作成できると指摘しました。

しかし、もちろん、すべてがメリットというわけではありません。欠点もあります。現状のmacOSインストーラーは、25年間のサポート期間中に「大きな技術的負債」を抱えており、macOSのファイルレイアウトに関するガイドラインに準拠しておらず、macOSのサンドボックス機能をサポートしていません。サンドボックス機能は、App Storeを通じてPythonを配布するために必要です。また、システム全体でインストールできる場所が一つしかないという点も、別の欠点でした。さらに、macOSのフレームワークのバージョン管理方式は、ABI（アプリケーションバイナリインタフェース）の互換性の問題から、Pythonのバージョン管理方式と一致していませんでした。

Free-threaded Python (python3t) は、既存のフレームワークビルドにサポートを組み込むのではなく、完全に独立した新しいフレームワークビルドを導入しました。しかし、Ned は、フリースレッドが最終的に Python のデフォルトになることで、この区別は長続きしないと考えています。

公式の Python macOS ディストリビューションは誰が利用しているのでしょうか？

Ned は、「正確なことは分かりませんが、推測することはできます」と述べ、macOS インストーラーのユーザー層について、「集中管理された IT 部門、公立学校、エンジニアリングまたは科学分野のユーザー、プログラミング初心者、実験者」などが含まれると考えています。py2app はフレームワークビルドを使用していますが、「動作させるためにビルドを改変する必要があります」。

Ned は、macOS 用の Python を構築・配布している他のプロジェクトをいくつか挙げました。Homebrew、MacPorts、Conda、uv、ActiveState、そして Apple が Xcode の LLDB の一部として提供しているものなどです。これらのプロジェクトは、python.org で提供されているビルドを使用していません。すべてが独自のディストリビューションを構築しています。

Łukasz Langa 氏は、Python 開発者調査で macOS インストーラーに関する質問が行われているかどうかを尋ねました。Ned は、それが良いアイデアだと同意しました。

次に何が？

Ned は、macOS と Python に関する自身の計画を述べ、話題を締めくくりました。彼は、CPython のプラットフォームサポートの詳細を記述する PEP 11 には、Windows に関するセクションがあるのに対し、macOS に関するセクションがないことに注意しました。彼は、macOS に関するセクションを提案し、他の主要開発者からのフィードバックを得る計画です。より一般的に、Ned は「macOS 全般のサポート」に関するポリシーを確立したいと考えており、Python を自分で構築したいユーザーを対象とし、サポート内容を詳細に記述することを目指しています。

現在、PEP 11 において、すべての 3 種類のビルドタイプとアーキテクチャは、「サポート」の観点から同じとみなされています。Ned は、これらのビルドをそれぞれ異なる PEP 11 のターゲットとして扱うべきかどうか疑問に思っています。これにより、ARM ベースの macOS と x86-64 ベースの macOS でサポートレベルを区別することができます。また、Ned は、iOS と macOS のビルドとパッケージングにおける共通点を活用したいと考えています。

ネッドは、パッケージングや継続的インテグレーションを含むビルドプロセスを自動化したいと考えています。これは、Pythonのリリースプロセスの一部としてWindowsがすでに持っている機能と似ています。さらに、ネッドはPythonのmacOSサポートを近代化したいと考えており、その中でPPCのユニバーサルビルドを廃止・削除し、従来のフレームワーク形式ではなく、XCFrameworkのパッケージングに移行することを目指しています。「多くの不要なものが残っています」。

しかし、使用されなくなったものをすべて削除できるわけではありません。AppleがIntel Macのサポートを完全に終了するとしても、ユニバーサルビルドの仕組みは少なくとも必要となる可能性があります。「ユニバーサルファットファイルビルド技術は30年以上も使用されており、AppleがCPUアーキテクチャを移行するたびに、この技術が使用されてきました。したがって、Appleが再びユニバーサルビルドを必要とする何らかの機能を追加する可能性は高いでしょう」。

ネイサン・ゴールバウムは、ネッドがPyManagerをmacOSに移植する予定があるかどうかを尋ねました。ネッドは、WindowsとmacOSでは内部構造が異なる可能性があると推測しましたが、ユーザーインターフェースは可能な限り類似させるべきだと考えました。ネッドは、ラッセル・キース・マギーが、この作業の出発点となる可能性のある小さなGUIアプリケーションを作成したと共有しました。

ルカシュ・ランガは、Glyph Lefkowitzが作成したツール「MOPUp（macOS Python.org Up dater）」について言及しました。このツールは、python.orgからmacOSのインストーラーを更新するものであり、特にこのツールの「高度な」機能である、Pythonのバージョンのアンインストール機能について言及しました。ネッドは、この機能は望ましいものであり、MOPUpはコマンドラインツールであるものの、数年前にはGlyphがmacOSインストーラーと連携して動作するマネージャーを作成したと述べています。