Различия между Framework и не-Framework-сборками Python в Mac OS X

Вопрос

Каковы различия между сборкой Framework и сборкой не-Framework (т.е. стандартной сборкой UNIX) Python в Mac OS X? Кроме того, каковы преимущества и недостатки каждого из них?

Предварительные исследования

Вот информация, которую я нашел до публикации этого вопроса:

  • [Pythonmac-SIG] Зачем нужна компоновка Framework для Python
    • В. Грейнджер: "Кажется, я помню, что для Python требуется сборка Framework, если вы хотите что-то сделать с собственным Mac GUI. Правильно ли я понимаю это?"
    • С. Баркер: "Довольно многое - для доступа к графическому интерфейсу Mac, приложение должно быть в подходящем комплекте приложений для Mac. Это обеспечивает сборку Framework."
  • Соединение с разработчиками Apple: определение платформы
    • "Рамка представляет собой набор (структурированный каталог), который содержит динамическую общую библиотеку вместе со связанными ресурсами, такими как файлы nib, файлы изображений и файлы заголовков. Когда вы разрабатываете приложение, ваш проект связывается с одним или несколькими Например, проекты приложений iPhone по умолчанию привязаны к фреймворкам Foundation, UIKit и Core Graphics. Ваш код обращается к возможностям инфраструктуры через интерфейс прикладного программирования (API), который публикуется каркасом через его заголовочные файлы. Поскольку библиотека динамически разделяется, несколько приложений могут одновременно обращаться к коду инфраструктуры и ресурсам. Система загружает код и ресурсы фреймворка в память по мере необходимости и разделяет одну копию ресурса среди всех приложений."
  • Руководство по программированию на платформе: что такое Framework?
    • "Frameworks предлагает следующие преимущества перед статическими библиотеками и другими типами динамических разделяемых библиотек:
      • Структура структур, связанных, но разделенных, ресурсов вместе. Эта группировка упрощает установку, удаление и поиск этих ресурсов.
      • Рамки могут включать более широкий набор типов ресурсов, чем библиотеки. Например, структура может включать любые соответствующие файлы заголовков и документацию. В один и тот же комплект можно включить несколько версий фреймворка. Это позволяет быть обратно совместимым со старыми программами.
      • Только одна копия ресурсов только для чтения основывается физически в памяти в любой момент времени, независимо от того, сколько процессов использует эти ресурсы. Это совместное использование ресурсов уменьшает объем памяти системы и помогает повысить производительность.

Фон

До Mac OS X 10.6 Snow Leopard я не думал об этом, так как просто загрузил и установил Python 2.6.2 Mac Installer Disk Image, который представляет собой сборку фреймворка, и занимаюсь своим бизнесом с помощью virtualenv, pip и т.д. Однако, с изменениями в Snow Leopard до 64-бит, gcc и т.д., Я заметил некоторые проблемы, которые заставили меня хотеть строить/компилировать Python 2.6.2+ самостоятельно из источника, что приводит меня к моему вопросу о различиях и преимуществах/недостатках построения Python в качестве инфраструктуры MacOSX | Darwin.

ОТВЕТЫ

Ответ 1

Вы уже указали все важные преимущества создания рамки (поздравляем за отличные исследования и отчетность!); единственная оборотная сторона состоит в том, что сложнее организовать его правильно, но если вы возьмете свои подсказки из приведенных вами примеров в программе установки, это должно быть выполнимо.

Кстати, что случилось с системой Python, которая поставляется с Snow Leopard? Я еще не обновился от Leopard (длинный рассказ... У меня есть лицензионный DVD-диск с семейной лицензией, но мне нужно Snow Leopard исправить некоторые вещи, прежде чем я смогу обновить), поэтому у меня нет опыта из первых рук., но я знаю, что это сборка 2.6, и она поставляется как в 32-битной, так и в 64-разрядной версиях... поэтому зачем вам создавать собственные фреймворки?

Ответ 2

Есть еще одно отличие: обычно установка Framework, предоставляемая установщиком из python.org, имеет несколько архитектур.

$ file libpython2.7.dylib

libpython2.7.dylib: Mach-O universal binary with 2 architectures libpython2.7.dylib (for architecture i386): Mach-O dynamically linked shared library i386 libpython2.7.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

Если вы устанавливаете из источника и не намеренно меняете это, ваш libpython имеет только одну архитектуру. У меня были случаи, когда две архитектуры фактически приводили к проблемам (по крайней мере, я полагаю, что это было причиной), а именно при установке привязок python HDF5 (h5py).

И есть еще одно отличие: некоторые инструменты требуют установки фреймов. Например, PyQt и, в частности, sip. Хотя можно установить sip и PyQt даже для не-фреймворческой версии python, это намного сложнее.

Что касается решения, что предпочесть, я до сих пор не знаю. На данный момент я пошел на вариант без рамки, но должен сказать, что это также вызвало у меня головную боль.

Ответ 3

Если вы собираетесь отправить свой код (если он работает на другом компьютере), вам лучше использовать системную версию python, иначе ваше поведение программы будет undefined на других машинах.

Ответ 4

Я использую Macports в 10.6, что очень упрощает установку нескольких версий python и переключайтесь между ними и версией Apple:

sudo port install python26
sudo port install python_select
sudo python_select -l

Самая последняя версия python26 - 2.6.2, и компилируется и работает отлично на 10.6.1: trac.macports.org/browser/trunk/dports/lang/python26/Portfile

Ответ 5

Рамочные сборки принадлежат учетной записи "root" при установке. Источник сборки будет принадлежать учетной записи, устанавливающей его. Преимущество (и недостаток) владения установкой Python заключается в том, что вам не нужно менять учетные записи, чтобы изменить его.

Небольшое различие заключается в том, что сборки Framework строятся против библиотеки EditLine. Исходные сборки обычно скомпилируются против библиотеки Readline. В зависимости от того, какая библиотека Python скомпилирована, модуль readline в стандартной библиотеке работает несколько иначе. См. "Man python" в Mac OS X для получения более подробной информации об этом.

Существует хорошая компоновка для автоматизации компиляции Python 2.4, 2.5 и 2.6 из исходного кода в Mac OS X, которая объясняется здесь, Это будет скомпилировано против пользовательской сборки readline. Однако полезность сценариев установки источника заключается в том, что вы можете внести дополнительные настройки в свои собственные сборки Python, например. устанавливая основные дистрибутивы, такие как virtualenv, или сложнее устанавливать дистрибутивы, такие как PIL.