Verschillen tussen Framework en niet-Framework builds van Python op Mac OS X

Wat zijn de verschillen tussen een Framework-build en een niet-Framework-build (d.w.z. standaard UNIX-build) van Python op Mac OS X? En wat zijn de voor- en nadelen van elk?

Vooronderzoek

Dit is de informatie die ik heb gevonden voordat ik deze vraag plaatste:

• [Pythonmac-SIG] Waarom is een Framework-build van Python nodig
  • B. Grainger: “Ik meen me te herinneren dat een Framework-build van Python nodig is als je iets wilt doen met de native Mac GUI. Klopt mijn begrip?”
  • C. Barker: “Vrijwel — om toegang te krijgen tot de Mac GUI, moet een app in een goede Mac-toepassingsbundel zitten. De Framework-build levert dat.”
• Apple Developer Connection: Framework-definitie
  • “Een framework is een bundel (een gestructureerde map) die een dynamische gedeelde bibliotheek bevat samen met bijbehorende bronnen, zoals nib-bestanden, afbeeldingsbestanden en headerbestanden. Wanneer u een toepassing ontwikkelt, wordt uw project gekoppeld aan een of meer iPhone-toepassingsprojecten zijn bijvoorbeeld standaard gekoppeld aan de Foundation-, UIKit- en Core Graphics-frameworks. Uw code heeft toegang tot de mogelijkheden van een framework via de Application Programming Interface (API), die door het framework wordt gepubliceerd via de headerbestanden. Omdat de bibliotheek dynamisch wordt gedeeld, hebben meerdere applicaties tegelijkertijd toegang tot de frameworkcode en bronnen. Het systeem laadt de code en bronnen van een framework indien nodig in het geheugen en deelt de ene kopie van een bron met alle applicaties.”
• Framework Programming Guide: Wat zijn Frameworks?
  • “Frameworks bieden de volgende voordelen ten opzichte van statisch gekoppelde bibliotheken en andere typen dynamische gedeelde bibliotheken:
    • Frameworks groep gerelateerde, maar gescheiden, bronnen samen. Deze groepering maakt het gemakkelijker om die bronnen te installeren, te verwijderen en te lokaliseren.
    • Frameworks kunnen een grotere verscheidenheid aan resourcetypen bevatten dan bibliotheken. Een framework kan bijvoorbeeld alle relevante headerbestanden en documentatie bevatten.
      Meerdere versies van een framework kunnen in dezelfde bundel worden opgenomen. Dit maakt het mogelijk om achterwaarts compatibel te zijn met oudere programma’s.
    • Slechts één kopie van de alleen-lezen bronnen van een framework bevindt zich fysiek in het geheugen op een bepaald moment, ongeacht hoeveel processen die bronnen gebruiken. Dit delen van bronnen vermindert de geheugenvoetafdruk van het systeem en helpt de prestaties te verbeteren.”

Achtergrond

Voorafgaand aan Mac OS X 10.6 Snow Leopard had ik hier niet veel over nagedacht, omdat ik gewoon de Python 2.6.2 Mac Installer Disk Image, een framework-build, en ga over mijn bedrijf met virtualenv, pip, enz. Echter, met de wijzigingen in Snow Leopard naar 64-bit, gcc, enz. ., Ik heb een aantal problemen opgemerkt waardoor ik Python 2.6.2+ zelf vanaf de bron wilde bouwen/compileren, wat me leidt tot mijn vraag naar de verschillen en voordelen/nadelen van het bouwen van Python als een MacOSX|Darwin-framework.

Antwoord 1, autoriteit 100%

Je hebt alle belangrijke voordelen van het maken van een raamwerk al op een rijtje gezet (gefeliciteerd met excellent onderzoek en rapportage daarvan!); de enige keerzijde is dat het moeilijker is om er een goed te bouwen, maar als je je aanwijzingen haalt uit de voorbeelden in het installatieprogramma dat je citeert, zou het te doen moeten zijn.

BTW, wat is er mis met het systeem Python dat wordt geleverd met sneeuwluipaard? Ik heb nog niet geüpgraded van Leopard (Long Story … ik heb de “Family License” -upgrade-dvd, maar heb sneeuwluipaard nodig om wat dingen te repareren voordat ik kan upgraden), dus ik heb nog geen ervaring met de eerste hand , maar ik weet dat het een 2.6-build is en het komt in zowel 32-bits als 64-bits versies … dus waarom moet je je eigen raamwerk opbouwen?

Antwoord 2, Autoriteit 31%

Er is nog een verschil: meestal heeft de kaderinstallatie die wordt verstrekt door het installatieprogramma van Python.org verschillende architecturen.

$ 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

Als u in de bron installeert en u dit niet opzettelijk verandert, heeft uw Libypython slechts één architectuur.
Ik heb gevallen gehad waar de twee architecturen daadwerkelijk resulteerden in problemen (ik geloof tenminste dat dit de reden was), namelijk bij het installeren van de HDF5 Python-bindingen (H5py).

En er is nog een ander verschil: sommige gereedschappen vereisen de framework-installatie. Bijvoorbeeld PYQT, en in het bijzonder SIP. Hoewel het mogelijk is om SIP en PYQT te installeren, zelfs voor de niet-raamwerkversie van Python, is het veel ingewikkelder.

Wat betreft de beslissing wat u wilt verkiezen, weet ik nog steeds niet. Op dit moment ging ik voor de niet-raamwerkoptie, maar ik moet zeggen dat het me ook wat hoofdpijn heeft veroorzaakt.

Antwoord 3, Autoriteit 8%

Als u uw code verzenden (laat deze op een andere machine uitgevoerd), kunt u beter de systeemversie van Python gebruiken, anders is uw programma-gedrag niet gedefinieerd op de andere machines.

Antwoord 4

Ik gebruik MACPORTS op 10.6, waardoor het heel eenvoudig is Installeer meerdere versies van Python en schakel tussen deze en Apple’s versie:

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

De meest recente versie van Python26 is 2.6.2, en compileert en loopt prima op 10.6.1:
Trac.macports.org/browser/Trunk/dports/lang/python26/portfile

Antwoord 5

Framework Builds zijn eigendom van het ‘root’-account bij het installeren. Een bronbuild is eigendom van het account dat het installeert. Het voordeel (en nadeel) van het eigendom van de Python-installatie is dat u geen account hoeft te wijzigen om het te wijzigen.

Een klein verschil is dat kaderbouwen is gebouwd tegen de EditLine-bibliotheek. Bron Builds worden meestal gecompileerd tegen de Readline-bibliotheek. Afhankelijk van welke bibliotheekpython is opgesteld tegen, werkt de Readline-module in de standaardbibliotheek enigszins anders. Zie ‘Man Python’ op Mac OS X voor meer informatie over dit.

Er is een mooie opbouw voor het automatiseren van de compilatie van Python 2.4, 2.5 en 2.6 van de bron op Mac OS X, die Hieruit uitgelegd . Dit zal compileren tegen een aangepaste building van readline. Het bruikbaarheid van het scripting van de broninstallatie is echter dat u extra tweaks kunt maken voor uw aangepaste Python-builds, b.v. Essentiële distributies installeren, zoals virtualenv of moeilijker om distributies zoals PIL te installeren.