2016-01-11 1 views
48

EDIT: J'ai posé une question d'opposition ici: How to embed Python3 with the standard libraryIntégrer python3 sans bibliothèque standard

Une solution pour python2 est fourni ici: Is it possible to embed python without the standard library?

Cependant, python3 échoue sur Py_Initialize(); avec:

Fatal Python error: Py_Initialize: unable to load the file system 
codec ImportError: No module named 'encodings' 

Cela est logique car les fichiers source py3 sont utf-8 par défaut. Il semble donc qu'il nécessite un binaire externe juste pour analyser les fichiers sources de py3.

Alors que faire?

Il semble que je devrais localiser le binaire encodings dans mon installation Python système, copiez-le dans mon arbre de projet, et peut-être définir une variable d'environnement PYTHONPATH (?) Pour que mon libpython.dylib puisse le trouver.

Est-il possible d'éviter cela? Et si non, quelqu'un peut-il clarifier les étapes à suivre? Y aura-t-il plus de hoquet?


NOTE: Pour la postérité, voilà comment je suis un autonome libpython.dylib liant dans mon projet sur Mac OS X:

D'abord je trouver mon système de bibliothèque de Python: /usr/local/Frameworks/Python.framework/Versions/3.4/Python (dans mon cas, il était installé avec homebrew).

Maintenant, je:

  • Copiez le .dylib dans mon dossier de projet de création ./Libs/libpython3.4.1_OSX.dylib

  • Allez dans build settings -> linking et mis other linker flags à -lpython3.4.1_OSX

À ce stade, il apparaît travailler. Cependant si vous savez essayer de le construire sur une nouvelle installation OSX, il échouera. C'est parce que:

$ otool -D ./libpython3.4.1_OSX.dylib 
./libpython3.4.1_OSX.dylib: 
/usr/local/Frameworks/Python.framework/Versions/3.4/Python 

Le .dylib tient encore à son ancien emplacement. C'est vraiment bizarre pour moi que le .dylib contienne un lien vers son emplacement, car tout ce qui l'utilise doit savoir où il se trouve pour l'invoquer en premier lieu!

Nous pouvons corriger cela avec:

$ install_name_tool -id @rpath/libpython3.4.1_OSX.dylib libpython3.4.1_OSX.dylib 

Mais aussi dans notre projet Xcode, nous devons:

  • Allez dans build phases. Ajouter une étape copy files qui copie libpython3.4.1_OSX.dylib à Frameworks (c'est le bon endroit pour le mettre).
  • Allez dans build settings -> linking et mettre runpath search paths à @executable_path/../Frameworks/libpython3.4.1_OSX.dylib

Enfin, je dois aller dans edit scheme -> run -> arguments -> environment variables et ajouter PYTHONHOME avec une valeur ../Frameworks

Je pense que pour obtenir ce travail, je vais aussi avoir besoin d'ajouter un PYTHONPATH

Liens:
https://mikeash.com/pyblog/friday-qa-2009-11-06-linking-and-install-names.html
http://qin.laya.com/tech_coding_help/dylib_linking.html
https://github.com/conda/conda-build/issues/279#issuecomment-67241554
Can you please help me understand how Mach-O libraries work in Mac Os X?
http://nshipster.com/launch-arguments-and-environment-variables/

+13

Je crains qu'il y ait plus d'exigences; l'importation de modules est largement gérée par le paquet 'importlib', par exemple. Je ne pense pas que Python 3 puisse être dépouillé du stdlib, du moins pas sans au moins un sous-ensemble. –

+0

'encodings' n'est pas un programme. C'est un paquet python – ppperry

+1

Essayez de lire la source du code de lancement de py2app. Il en sait beaucoup sur OS X et fait fonctionner python. –

Répondre

2

J'ai essayé cela et il faudrait plus de temps que vous voulez passer à intégrer Python 3 sans la bibliothèque Python.

Certains modules de la bibliothèque sont nécessaires à l'exécution de Python 3 et il faudrait beaucoup de modifications pour qu'il fonctionne sans eux.

+0

Ceci n'est pas une bonne réponse du tout, aucune explication de pourquoi tout ce que vous dites est le cas, et une explication des discontinuités entre python 2.x fonctionnant pour ceci et python 3.x ne fonctionne pas. – snb

+0

Python 3 possède actuellement plusieurs dépendances codées en dur telles que encodings.utf_8, encodings.latin_1, builtins, io. Il importe les modules lors de l'initialisation. Ce n'était pas le cas dans Python 2. Il n'y a pas grand chose d'autre à dire. – Alden