python-2.7 pycharm setuptools

python 2.7 - Símbolo no encontrado:__PyCodecInfo_GetIncrementalDecoder



python 2.7 13 (12)

Desde la actualización desde Homebrew Python 2.7.11 (desde 2.7.10) de repente no puedo probar registrar mi paquete en PyPi desde la consola PyCharm IDE.

En ejecución (como una "Herramienta externa")

python -B setup.py register -r pypitest

Ahora tengo

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

No estoy seguro de cómo proceder. Solo obtengo este problema si ejecuto desde la consola de mi IDE. Si lo hago directamente en la línea de comando del sistema (Terminal en OS X) no tengo problemas.

OS X 10.11.3; Homebrew Python 2.7.11; PyCharm 5.0.3

De acuerdo con https://github.com/klen/python-mode/issues/634 :

Tuve el mismo problema, pero lo solucioné correctamente. En mi caso, compilé python y vim con homebrew, cuando PYTHON_PATH se ha especificado y configurado en uno de mis entornos de desarrollo, donde también tenía algunas bibliotecas, incluida io. La solución era simple: abra una nueva terminal, asegúrese de que no tiene PYTHON_PATH personalizada, desinstale python, desinstale vim. Vuelva a instalar los dos.

y

Problema resuelto.

El culpable es la actualización de Python 2.7.10 a 2.7.11.

Si está utilizando el control de paquete conda, simplemente ejecute "conda install python = 2.7.10" para resolver este problema.

Sin embargo, esto no da la causa raíz. Como esto sucede con _io , esto parece un error en Python 2.7.11 (poco probable, habría una protesta a escala mundial y una pronta solución si lo fuera) o algún error de empaque o una versión que no coincida específicamente con la versión homebrew (y tal vez algunos relacionados también).

Intente import _io en la consola y, si tiene éxito, verifique si se cargó desde la misma ruta.

Esto me pasó a mí también en MacVim. Lo resolví asegurándome :python print(sys.path) está usando el sistema Python (por ejemplo, /Library/Python/2.7/... )

Desde que instalé MacVim a través de Homebrew, lo hice de la siguiente manera:

  1. Genera un nuevo shell que tenía which python -> /usr/bin/python . Para mi caso, necesitaba eliminar la línea pyenv de mi .bash_profile . Si instaló Python a través de Homebrew, es posible que desee brew unlink python primero

  2. brew reinstall macvim

Esto sucedió cuando ya había intentado crear un venv en una carpeta, ¡y por error estaba tratando de inicializar una segunda! Así que simplemente eliminé el directorio venv y volví a ejecutar el comando. Es muy probable que esta no sea la respuesta a esta solución, pero buscar mi error me trajo aquí, por lo que puede ayudar a otros que están atascados.

No puedo agregar comentarios (?) Así que esto solo para compartir mi exp., Bajar a 2.7.10 funciona para mí.

Otra solución rápida si no le importa seguir con Python 2.7.10 es especificar la ruta del ejecutable del intérprete de Python que se utilizará para virtualenv. En OSX, esa ruta suele ser /usr/bin/python :

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

Recibí este error después de una descarga fallida de NLTK, necesitaba desinstalar anaconda:

sudo rm -rf ~/anaconda update PATH variable

Resolví este problema eliminando el enlace simbólico que estaba en /usr/local/bin y copiando el binario real de python, que dicho enlace señalaba allí.

Si su problema es causado por anaconda , no es necesario eliminar el directorio //anaconda .

Simplemente abra su ~/.bash_profile , encuentre la línea

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

y comentarlo, luego reinicie su sesión de terminal.

Tuve el mismo problema cuando intenté usar PyCharm. Se resolvió estableciendo el "intérprete de Python" en la configuración del proyecto para apuntar al entorno virtual de Python que quería usar, que era un entorno de Anaconda. De alguna manera, a la ruta del intérprete le faltaba la parte "anaconda" de ~ /.../ anaconda /.../_ io.so. No es necesario desinstalar anaconda.

Tuve el mismo problema, se solucionó con éxito simplemente reemplazando el archivo _io.so.

sudo find / -name _io.so

copie la ruta del archivo _io.so que NO pertenece a python-2.7.11. Por ejemplo, copie la ruta de _io.so que se encuentra en python-2.7.5: /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib- dynload / _io.so

Reemplace el archivo /usr/local/Cellar/python/2.7.11/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_io.so con el _io.so que acaba de encontrar.

Vuelva a instalar Python.

brew unlink python && brew reinstall python

Asegura el camino

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

COPIA DE SEGURIDAD y cambiar el orden del archivo "caminos".

sudo nano /etc/paths

Al parecer, el orden de los caminos, es decisivo para ejecutar Python correctamente. En mi caso, el resultado fue:

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

En mi mac, el camino es así.

$ which python /usr/local/bin/python

Ahora puedo ejecutar ambos:

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

tl; dr: solucione este problema siguiendo uno de estos procedimientos:

  • escriba hash -r python , OR
  • cerrar sesión e iniciar sesión.

EDITAR: Una respuesta a mi pregunta relacionada deja en claro lo que está sucediendo aquí. Cuando instala una nueva versión de python, es posible que deba ejecutar hash -r python para indicarle a bash que restablezca la ubicación "en caché" al ejecutable de python .

En mi caso, estaba escribiendo python , que estaba en mi $PATH en /usr/local/bin/python . Pero bash todavía estaba usando la antigua ubicación de caché /usr/bin/python . Entonces, se llamó al antiguo ejecutable, pero se proporcionó la nueva ruta a python en sys.argv[0] . Esto significa que el antiguo ejecutable se estaba ejecutando, pero el nuevo valor sys.executable hizo que se sys.executable todos los módulos incorrectos (incluido el módulo io ).

Estoy teniendo el mismo problema. Instalé python 2.7.11 a través de un instalador de Python.org. Curiosamente, el problema parece estar relacionado con alguna diferencia sutil entre cómo OSX inicia python cuando lo invoco desde el shell usando la ruta completa frente a usar solo la palabra python .

Entonces, para mí, esto funciona (invocando python a través de la ruta completa /usr/local/bin/python ):

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

... pero esto no:

$ 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

Entonces, como solución alternativa, puede intentar hacer lo mismo.

En otro lugar, he publicado una pregunta por separado sobre este comportamiento desconcertante. ¿Quizás de alguna manera simplemente llamar a python invoca una extraña mezcla del ejecutable 2.7.11 con los dylibs 2.7.10?