Pipenv: 2018.11.26: pipenv emite errores de pitones al crear un virtualenv

Parece que /usr/local/bin/pythonz ya no es una ruta válida.

Hmm. ¿Debería haberlo sido alguna vez? Nunca he usado pythonz directamente. Pensé que era solo una dependencia de pipenv que administraba cuando instalé pipenv.

Por diversión, acabo de desinstalar y reinstalar pipenv 2018.11.26 y todavía tengo el problema.

¿Puede proporcionar la salida de pipenv --support ? Y para confirmar, no, no debería haber sido

Oh, NVM acaba de ver tu mensaje. Solo quiero confirmar que no hay una versión falsa de pipenv en su camino en algún lugar. ¿Puede comprobar which pipenv y python -m pipenv --version

$ which pipenv
/usr/local/bin/pipenv

python -m pipenv --version devolvió No module named pipenv porque tengo Python 2 y Python 3 instalados a través de Homebrew, y python ejecuta Python 2.7. Según una recomendación anterior aquí, tengo pipenv instalado en Python 3. Así que lo sustituí en python3 y obtuve:

$ python3 -m pipenv --version
pipenv, version 2018.11.26

¡Gracias!

Ah ok. Y sí, el error tiene sentido. Lo etiquetaré aguas arriba y me aseguraré de que se arregle

¿Alguna noticia sobre cuándo se lanzará una solución para esto? Tengo este problema que me impide instalar los requisitos de pipenv. He tratado solución @commandtab 's con esa suerte.

No puedo hacer que pipenv funcione en absoluto con la versión actual.

$ which pipenv
/Users/josh/.pyenv/shims/pipenv

$ python -m pipenv --version
pipenv, version 2018.11.26

Intenté instalar con python3.7 desde homebrew, y el mismo problema.

Parece que no hay urgencia aquí, o que no es un gran problema. ¿Me falta algo o pipenv está completamente roto con la versión actual?

El lanzamiento actual me parece seguro. Otra solución temporal que vi en un número anterior fue pasar específicamente una ruta python así:

pipenv --three --python=`which python3`

He estado haciendo esto con éxito por el momento: muecas:

Esa solución no me funcionó. Tuve que degradar a 2018.10.13 y luego usar la solución en ese hilo :

pipenv install -d --python=$HOME/.pyenv/versions/3.7.1/bin/python

Por lo que puedo decir, pipenv se ha roto por completo desde octubre.

@techalchemy ¿ Alguna noticia sobre una corrección de etiquetas ascendentes? La creación de pipenv virtualenv aún requiere soluciones alternativas para la invocación.

Gracias ❤️

Esto fue un poco difícil con todas las otras correcciones que debían integrarse, pero creo que CI pasará ahora y esto se solucionará con # 3330, lo siento por el problema.

Ah ok. Y sí, el error tiene sentido. Lo etiquetaré aguas arriba y me aseguraré de que se arregle

Aún el problema persiste, cualquier idea de cuándo se lanzará esta solución.

El mismo problema aquí.

Puede confirmar que la solución alternativa de @ command-tab aún funciona.

Esto definitivamente todavía sucede con homebrew pipenv y python ... un poco sorprendido de que no haya una prueba para cubrirlo viendo cuánto tiempo ha existido este problema ...

También puedo confirmar que este problema sigue ocurriendo, a pesar de que este problema de GitHub está cerrado.

¿Necesitan los mantenedores que se cree un nuevo problema?

El mismo problema con Ubuntu 18 LTS instalado en el subsistema de Windows para Linux.

La solución me funciona.

@techalchemy, este problema todavía parece existir. ¿Puede volver a abrirlo o dejar en claro que desea que se cree un nuevo problema?

Gracias.

El mismo problema con Ubuntu 18 LTS instalado en el subsistema de Windows para Linux.

igual que aquí

@techalchemy por favor mira de nuevo

El mismo problema aquí en macOs Mojave y Python 3.7

Yo también:

• Catalina
• Python 3.7.

Todo funciona bien una vez que comento esta línea en mi Pipfile:

[requires]

#python_version = "3.7.4"

Yo también:

• Catalina
• Python 3.7.

Todo funciona bien una vez que comento esta línea en mi Pipfile:

[requires]

#python_version = "3.7.4"

ahhhh esto funcionó para mí, ¡gracias!

@JarredStanford @edsu
Esto también funcionó para mí en WSL en VSCode (no probé un shell externo ya que funcionó bien para un proyecto diferente).

@ pestaña-comando
Agregar "--python = which python3 " también funcionó. No intenté agregar "--three" y parece que no es necesario para mi caso de uso / versión.

Después de obtener ambas soluciones y pude hacer que funcionara, las eliminé e intenté una tercera vez para asegurarme de que el entorno todavía estaba causando un problema (narrador: sí).

@techalchemy
Estoy pensando que esto puede no estar "completamente arreglado" en 3330. Podría ser un problema tangencial que cause los mismos síntomas. En mi caso, estoy usando WSL y me pregunto si 'python3' y 'python3.exe' ambos en mi ruta WSL parece sospechoso.

¿Crees que es mejor que abra un nuevo problema, te gustaría que ejecutara diagnósticos adicionales o algo más?

Estoy usando wsl2 con arclinux (manjaro)
Parece que pipenv está llamando a Python en Windows env del host para instalar
por lo que necesitamos definir dónde encontrar la pitón con:
pipenv --python=<PATH_TO_PYTHON>
o
pipenv --python=which python3

funciona para mi.

Puede confirmar que esto sucede en WSL con Ubuntu 18.04 LTS. Parece que pipenv está buscando un intérprete de Python en lugar de usar el que se está ejecutando, y al hacerlo, está atravesando PATH en orden inverso. Tengo varios entornos de Python instalados, y cada vez que elimino manualmente uno de PATH, pipenv encontrará uno diferente y se quejará de ese.

Veo el mismo problema en WSL con Ubuntu 18.04 LTS. pipenv install --python $(which python3) funciona pero cuando luego hago pipenv shell , no puede encontrar las dependencias que debería haber descargado.

También estoy afectado, usando WSL 1 y Ubuntu 18.04. La solución alternativa --python $(which python) funciona.

El motivo de la última parte de la excepción, es decir, este bit:

  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pythonfinder/utils.py", line 68, in get_python_version
    combine_stderr=False, write_to_stdout=False)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/vistir/misc.py", line 314, in run
    write_to_stdout=True
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/vistir/misc.py", line 162, in _create_subprocess
    sys.stderr.write("Error %s while executing command %s", exc, " ".join(cmd._parts))
TypeError: write() takes exactly one argument (3 given)

... es porque hay un error en la llamada para imprimir un error al manejar la primera excepción. Este error parece que ya se corrigió en el maestro en enero de 2019: https://github.com/pypa/pipenv/commit/574fe7308d9ac81d64da954722f35c9eee0dd467#diff -a59595db75020aeb9f688d6a0b4818e6L162. Pero dado que la última versión de pipenv es 2018.11.26, imagino que la mayoría no tiene una versión fija.

Uno puede parchearlo manualmente. Abra /usr/local/lib/<your-python-version>/site-packages/pipenv/vendor/vistir/misc.py , navegue hasta la línea 162 y cambie esto:

sys.stderr.write("Error %s while executing command %s", exc, " ".join(cmd._parts))

... a esto:

sys.stderr.write(f"Error {exc} while executing command " + " ".join(cmd._parts))

Ahora obtendrá un informe de excepción más preciso. En mi caso, el problema es que pipenv basado en Linux WSL detecta las instalaciones de Python basadas en Windows y tiene problemas para ejecutarlas, lo cual es algo obvio:

Error [Errno 8] Exec format error: '/mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe' while executing command /mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe -c import sys; print(['Traceback (most recent call last):\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/contextmanagers.py", line 150, in spinner\n    yield _spinner\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 314, in run\n    write_to_stdout=True\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 160, in _create_subprocess\n    combine_stderr=combine_stderr)\n', '  File "/usr/local/lib/python3.6/dist-packages/pipenv/vendor/vistir/misc.py", line 134, in _spawn_subprocess\n    return subprocess.Popen(cmd, **options)\n', '  File "/usr/lib/python3.6/subprocess.py", line 729, in __init__\n    restore_signals, start_new_session)\n', '  File "/usr/lib/python3.6/subprocess.py", line 1364, in _execute_child\n    raise child_exception_type(errno_num, err_msg, err_filename)\n', "OSError: [Errno 8] Exec format error: '/mnt/c/Users/<user>/AppData/Local/Microsoft/WindowsApps/python3.exe'\n"]

Para los usuarios de WSL, creo que el problema puede aliviarse asegurándose de que cualquier requisito en su versión de Python en Pipfile coincida _exactamente_ con una instalación de Python basada en Linux, por ejemplo

[requires]
python_version = "3.6.8"  # Make sure this exactly matches an installed version, or remove it.

Espero que esto ayude.

No estoy seguro de cuánto ayuda esto, pero eliminar el Pipfile, ejecutar pipenv lock y luego volver a poner el contenido del antiguo Pipfile y ejecutar pipenv install funciona para mí de forma permanente.