web-dev-qa-db-fra.com

Symbole introuvable: __PyCodecInfo_GetIncrementalDecoder

Depuis la mise à jour à partir de Homebrew Python 2.7.11 (à partir de la version 2.7.10), je ne peux tout à fait pas enregistrer mon paquet sur PyPi à partir de la console PyCharm IDE.

En cours d'exécution (en tant qu '"outil externe")

python -B setup.py register -r pypitest

Je reçois maintenant

Traceback (most recent call last):
  File "setup.py", line 22, in <module>
    from setuptools import setup
  File "/usr/local/lib/python2.7/site-packages/setuptools/__init__.py", line 12, in <module>
    from setuptools.extension import Extension
  File "/usr/local/lib/python2.7/site-packages/setuptools/extension.py", line 8, in <module>
    from .dist import _get_unpatched
  File "/usr/local/lib/python2.7/site-packages/setuptools/dist.py", line 16, in <module>
    from setuptools.depends import Require
  File "/usr/local/lib/python2.7/site-packages/setuptools/depends.py", line 6, in <module>
    from setuptools import compat
  File "/usr/local/lib/python2.7/site-packages/setuptools/compat.py", line 17, in <module>
    import httplib
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 80, in <module>
    import mimetools
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/mimetools.py", line 6, in <module>
    import tempfile
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/tempfile.py", line 32, in <module>
    import io as _io
  File "/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
    import _io
ImportError: dlopen(/usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
  Referenced from: /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
  Expected in: flat namespace
 in /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so

Process finished with exit code 1

Je ne sais pas comment procéder. Je ne reçois ce problème que si j'exécute depuis la console de mon IDE. Si je le fais directement sur la ligne de commande du système (Terminal sous OS X), je n’ai aucun problème.

OS X 10.11.3; Homebrew Python 2.7.11; PyCharm 5.0.3

python-2.7pycharmsetuptools
73
orome

tl; dr: corrigez ce problème en effectuant l'une des opérations suivantes:

  • tapez hash -r python, OR
  • déconnectez-vous et connectez-vous.

EDIT: Une réponse à ma question connexe montre clairement ce qui se passe ici. Lorsque vous installez une nouvelle version de python, vous devrez peut-être exécuter hash -r python pour indiquer à bash de réinitialiser l'emplacement "mis en cache" sur l'exécutable python.

Dans mon cas, je tapais python, qui se trouvait sur mon $PATH à /usr/local/bin/python. Mais bash utilisait toujours l'ancien emplacement de cache /usr/bin/python. Ainsi, l'ancien exécutable a été appelé, mais le nouveau chemin a été fourni à python dans sys.argv[0]. Cela signifie que l'ancien exécutable était en cours d'exécution, mais la nouvelle valeur sys.executable provoquait le chargement de tous les modules incorrects (y compris le module io).

J'ai le même problème. J'ai installé python 2.7.11 via un programme d'installation de Python.org. Étrangement, le problème semble être lié à une différence subtile entre la façon dont OSX lance python lorsque je l’invoque depuis le shell en utilisant le chemin complet par opposition à l’utilisation du mot python.

Donc, pour moi, cela fonctionne (en invoquant python via le chemin complet /usr/local/bin/python):

$ which python
/usr/local/bin/python
$ /usr/local/bin/python -c "import io"
$

... mais cela ne veut pas:

$ python -c "import io"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/io.py", line 51, in <module>
    import _io
ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so, 2): Symbol not found: __PyCodecInfo_GetIncrementalDecoder
  Referenced from: /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so
  Expected in: flat namespace
 in /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so

Donc, pour contourner le problème, vous pouvez essayer de faire la même chose.

Ailleurs, j'ai posté un question distincte à propos de ce comportement déroutant. Peut-être qu’appelant simplement python invoque un étrange mélange de l’exécutable 2.7.11 avec les 2.7.10 dylibs ??

199
Stuart Berg

Selon https://github.com/klen/python-mode/issues/634 :

J'ai eu le même problème, mais résolu avec succès. Dans mon cas, j'ai compilé python et vim avec homebrew, lorsque PYTHON_PATH a été spécifié et défini sur l'un de mes environnements de développement, où j'avais également quelques bibliothèques, y compris io. La solution de contournement était simple: ouvrez un nouveau terminal, assurez-vous de ne pas avoir personnalisé PYTHON_PATH, désinstallez python, désinstallez vim. Réinstallez les deux.

et

Problème résolu.

Le coupable est la mise à jour de python 2.7.10 à 2.7.11.

Si vous utilisez le contrôle de package conda, exécutez simplement "conda install python = 2.7.10" pour résoudre ce problème.

Cela ne donne cependant pas la cause première. Comme cela se produit avec _io, cela ressemble à un bogue dans python 2.7.11 (peu probable, il y aurait un tollé à l'échelle mondiale et un correctif Prompt s'il était), ou un bogue d'emballage ou incompatibilité de version spécifiquement avec la version homebrew (et peut-être certaines connexes, aussi).

Essayez de import _io dans la console et si cela réussit, vérifiez s'il a été chargé à partir du même chemin.

21
ivan_pozdeev

Réinstallez Python.

brew unlink python && brew reinstall python

Sécuriser le chemin

export PYTHONPATH=$PYTHONPATH:/usr/local/bin/

BACKUP et Changer l'ordre du fichier "chemins".

Sudo nano /etc/paths

il semble que, dans l’ordre des chemins, il soit décisif d’exécuter correctement python. Dans mon cas, le résultat était:

#Sudo nano /etc/paths
  /usr/bin  
  /usr/local/bin
  /bin
  /usr/sbin
  /sbin

Sur mon mac, le chemin est comme ça.

$ which python
    /usr/local/bin/python

Maintenant je peux courir les deux:

$ /usr/local/bin/python -c "import io"
$ python -c "import io"
11
Noel Ruault

J'ai eu le même problème, il est résolu avec succès en remplaçant simplement le fichier _io.so.

Sudo find / -name _io.so

copier le chemin du fichier _io.so qui NE FAIT PAS appartient à python-2.7.11. Par exemple, copiez le chemin de _io.so qui se trouve sous python-2.7.5: /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib- dynload/_io.so

Remplacez le fichier /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so par le fichier _io.so que vous venez de trouver.

6
Yanan

Cela m'est arrivé aussi à MacVim. Je l'ai résolu en m'assurant que :python print(sys.path) utilise système Python (par exemple /Library/Python/2.7/...)

Depuis que j'ai installé MacVim via Homebrew, je viens de le faire en:

  1. Crée un nouveau shell qui avait which python -> /usr/bin/python. Pour mon cas, je devais supprimer la ligne pyenv de mon .bash_profile. Si vous avez installé Python via Homebrew, vous souhaiterez peut-être commencer par brew unlink python

  2. brew reinstall macvim

3
kizzx2

Une autre solution rapide, si vous voulez bien vous en tenir à Python 2.7.10, est de spécifier le chemin d'accès de l'exécutable interpréteur Python qui sera utilisé pour virtualenv. Sur OSX, ce chemin est généralement /usr/bin/python:

virtualenv venv --python=/usr/bin/python
3
skeller88

Si votre problème est causé par anaconda, il est inutile de supprimer le répertoire //anaconda.

Ouvrez simplement votre ~/.bash_profile, trouvez la ligne

export PATH="//anaconda/bin:$PATH

et commentez-le, puis redémarrez votre session de terminal.

2
Will

J'ai eu cette erreur après un téléchargement échoué de NLTK, j'avais besoin de désinstaller anaconda:

Sudo rm -rf ~/anaconda 
update PATH variable
1
user260826

Vous ne pouvez pas ajouter de commentaire (?), Alors il suffit de partager mon expérience. La mise à niveau vers la version 2.7.10 fonctionne.

1
tngn

Cela s'est produit alors que j'avais déjà essayé de créer un fichier venv dans un dossier et que, par erreur, j'essayais d'en initialiser un deuxième! Je viens donc de supprimer le répertoire venv et de relancer la commande. Très probablement, ce n’est pas la solution à cette solution, mais la recherche de mon erreur m’a amené ici. Cela pourrait donc aider d’autres bloqués.

0
Ethan Keller

J'ai eu le même problème lorsque j'ai essayé d'utiliser PyCharm. Résolu en réglant "interprète python" dans la configuration du projet pour qu'il pointe vers l'environnement virtuel python que je voulais utiliser, qui était un env Anaconda. D'une manière ou d'une autre, le chemin de l'interprète manquait de la partie "anaconda" de ~ /.../ anaconda /.../_ io.so. Pas besoin de désinstaller anaconda.

0
Kai

J'ai résolu ce problème en supprimant le lien symbolique qui se trouvait dans /usr/local/bin et en copiant le binaire réel python, pointé par ledit lien, à cet endroit.

0
Chris Goy