+1, confirmado con Mac OS X 10.7.3 y Python 2.7.1

Un poco molesto, sería genial tener una solución

Podemos crear un virtualenv con espacios en el nombre (ver # 278), pero easy_install y pip tropiezan con él más tarde:

% virtualenv "foo bar"
New python executable in foo bar/bin/python
Installing setuptools............done.
Installing pip...............done.
% ./foo\ bar/bin/easy_install nose
zsh: ./foo bar/bin/easy_install: bad interpreter: "/tmp/cfl/foo: no such file or directory
127 % ./foo\ bar/bin/pip install nose 
zsh: ./foo bar/bin/pip: bad interpreter: "/tmp/cfl/foo: no such file or directory

También estoy aquí para confirmar que este es un problema con OS X (10.8 aquí). Si edita la variable VIRTUAL_ENV y shebangs en bin, puede hacer que funcione, pero un nuevo env se ahoga en cualquier espacio en una ruta. Lo cual es un gran problema para OS X, dado que la unidad de arranque generalmente se llama "Macintosh HD", por lo que cada ruta comienza con "/ Volumes / Macintosh HD ..."

El truco que estoy usando funciona de la siguiente manera.

bin / activar:

VIRTUAL_ENV='/Volumes/Macintosh\ HD/path/to/my/project'

bin / pip y bin / easy_install:

#!"/Volumes/Macintosh\ HD/path/to/my/project/venv/bin/python"

Pip parece estar trabajando después de escapar del espacio en el camino.

¿Por qué estaba esto cerrado? Sigue siendo un gran problema. edita mi error, todavía está abierto

este problema todavía se muestra abierto.

Pude evitar esto creando un enlace simbólico desde mi directorio de inicio al en el que quería trabajar (que de lo contrario tenía un espacio).

También veo esto porque Mac. Soluciono esto editando manualmente la línea shebang en los scripts a! # / Usr / bin / env python y todo funciona. Sin embargo, como han mencionado otros, esto debe hacerse con cada nuevo env y cualquier script adicional instalado en el env.
Parece que esto debería ser una solución fácil en el código para escapar del espacio o usar / usr / bin / env if is_darwin. Sin embargo, como soy prácticamente un novato en esto, podría estar equivocado.

Esto no es solo para mac, es básicamente parte de la especificación / comportamiento de los sistemas * nix.

No puede tener espacios en el primer argumento de la línea shebang (en su lugar, se convertirán en argumentos separados), y normalmente tampoco se permite escapar / citar.

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

Lo sé, también me encontré con este problema con anaconda. Es endémico de Mac porque el nombre de la unidad tiene espacios en blanco.

Parece que esto sería corregido por el # 611. ¿Ha habido alguna revisión de la eficacia de esa solicitud de extracción?

Tan molesto, debería arreglarse lo antes posible.

Vea el enlace que publicó @Ivoz , esta es una limitación de Unix. # 611 podría funcionar para algunas variantes de Unix, si admiten escapes de barra invertida en una línea shebang, pero no está claro qué versiones lo hacen (y el código simplemente lo hace a ciegas sin verificar, lo que ciertamente no hará que el problema sea peor, pero ganó ''. tampoco ayuda si no es compatible ...)

De hecho, es cierto que esto es el resultado de la forma en que Unix maneja las líneas shebang, pero si el # 611 soluciona el problema para algunos sistemas y no empeora el problema para otros, ¿sería eso una mejora?

Si eso es cierto, entonces sí. Pero no puedo comentar sobre el # 611 ya que no soy desarrollador de Unix. Puede haber casos en los que empeore las cosas, simplemente no lo sé. Lo siento, no puedo ser de más ayuda.

Lo suficientemente justo. El # 611 probablemente deba ser examinado y probado más cuidadosamente para casos marginales.

Peor aún: en Windows se rompe en la ruta predeterminada de Jenkins con el mismo error:
FATAL: no se permiten espacios en blanco en la ruta del intérprete de Python: C: \ Archivos de programa (x86) \ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41d8cd9

Solo me afectó este problema. Siguiendo las instrucciones que encontré en StackOverflow , logré hacer que pip funcionara simplemente configurando la primera línea en #!/usr/bin/env python

Sin embargo, no estoy seguro de si esa solución funciona para todos los casos ... quiero decir, no estoy seguro de qué Python se ejecutará

Cambiar el shebang de los scripts instalados a “env python” significa que solo funcionarán en un virtualenv activado. Los scripts se generaron con rutas absolutas explícitas para que siempre usaran Python en el venv y así encontrar los paquetes instalados necesarios para los scripts.

Mi sugerencia sería que alguien (probablemente alguien afectado por este problema, pero como mínimo alguien en una plataforma que tenga el problema y que también tenga una forma de resolverlo) proporcione una solicitud de extracción que implemente una verificación del tipo:

• Si tenemos espacios en el nombre de la ruta,
• y estamos en la plataforma XXX,
• luego escriba la línea shebang con el siguiente escape para manejar los espacios.
• En todos los demás casos, vuelva al comportamiento actual.

Las partes interesadas podrían hacer más adiciones simplemente agregando controles adicionales de la plataforma.

Idealmente, sería bueno incluir un comentario con un enlace a la documentación que confirme cómo la plataforma XXX admite rutas con espacios, para que los futuros mantenedores tengan una referencia para verificar. Personalmente, no tengo claro qué correcciones funcionan y dónde:

1. la discusión aquí sugiere que las comillas dobles funcionan en OSX, pero ¿eso depende de la versión precisa de OSX?
2. En el n. ° 611 se usaron espacios de escape con barras invertidas, pero no hubo confirmación sobre para qué sistema operativo era (¿Linux? ¿Una versión específica del kernel?

Tenga en cuenta que ninguna de estas variantes específicas de la plataforma debe usar /usr/bin/env . Como señaló @merwok , eso da como resultado un cambio en el comportamiento: el shebang se escribe deliberadamente para permitir ejecutar el script _sin_ activar el entorno.

Agregar algunas pruebas para asegurarse de que el comportamiento sea el esperado (incluido el principio de que retrocede cuando no estamos en una plataforma específicamente reconocida) también sería extremadamente útil, pero también sería complicado, ya que implicaría un parche de mono para permite realizar pruebas para la plataforma XXX cuando no se esté ejecutando en esa plataforma.

@pfmoore Como mencioné, este problema me afectó recientemente y estoy ejecutando Linux Mint 18. Nunca he contribuido con Virtualenv, pero actualmente estoy en Python Brasil y tendremos un día dedicado a los sprints, podría darle ¡un intento!

escapar con barras invertidas o comillas no funcionará, según https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html

Experimentalmente, puedo verificar que escapar con barras invertidas o comillas no funciona con OSX 10.11.6.

virtualenv debe mantenerse alejado de los shebangs que dependen del kernel. He comprobado los códigos fuente de Linux, XNU (kernel de macOS), FreeBSD, OpenBSD y NetBSD. Ninguno de ellos puede manejar espacios en shebang.

Antes de que haya una solución, no use espacios.

Envío un parche que agrega una advertencia para el nuevo venv de Python 3, que es bastante similar a virtualenv pero rechazado por @vsajip : http://bugs.python.org/issue28446. De hecho, no es culpa de Python, sino de un sistema operativo. ¿Quizás este tema se pueda solucionar?

Como punto de datos adicional, tenga en cuenta el comportamiento en Windows, que parece ser el esperado:

`` `C: \ Usuarios \ Vinay> \ python34 \ python -m venv" \ Temp \ aaa bbb "

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" - versión
pip 6.0.8 de C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)

C: \ Users \ Vinay> pyzzer -i "\ Temp \ aaa bbb \ Scriptspip.exe"
Hay un lanzador.
Shebang: #! "C: \ Temp \ aaa bbb \ Scripts \ python.exe"

Contenido del archivo:
__main__.py

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
Está utilizando pip versión 6.0.8, sin embargo, la versión 9.0.1 está disponible.
Debería considerar la actualización a través del comando 'pip install --upgrade pip'.
Recopilando pip de https://pypi.python.org/ [...] / pip-9.0.1-py2.py3-none-any.whl # md5 = 297 [...]
Usando pip-9.0.1-py2.py3-none-any.whl en caché
Instalación de paquetes recopilados: pip
Instalación existente encontrada: pip 6.0.8
Desinstalación de pip-6.0.8:
Pip-6.0.8 desinstalado con éxito

Pip-9.0.1 instalado con éxito

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" - versión
pip 9.0.1 de C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)
''

Sí, los scripts virtualenv en Windows funcionan ya que distlib define su propio protocolo shebang en PC / launcher.c. Quizás POSIX pueda tener algo similar: un analizador de shebang de espacio de usuario en lugar de kernels poco confiables.

un analizador shebang de espacio de usuario en lugar de kernels no confiables

No estoy seguro de por qué Bash no puede hacer esto (por ejemplo); no creo que sea una cosa del espacio del kernel.

Los shebangs se manejan en el espacio del kernel porque deberían ser utilizables fuera de los shebangs.

Detalles técnicos:
En sistemas similares a UNIX (Linux, Mac, * BSD, ...), se crea un nuevo programa mediante fork () y exec (). exec () es similar a CreateProcess () en Windows, que ejecuta un nuevo programa. En sistemas similares a UNIX, exec () eventualmente llama a la llamada al sistema execve (). La última función se implementa en los núcleos, por lo que el análisis de shebang se realiza en los núcleos.
Tampoco se puede implementar en bibliotecas C, o los programas vinculados estáticos o los programas que usan llamadas al sistema directamente (a través de int 80 o sysenter, etc.) no funcionarán.

Quizás deberíamos prohibir la creación de un entorno virtual con espacios en el camino. No funcionará como se esperaba de todos modos

Los shebangs se manejan en el espacio del kernel porque deberían poder usarse fuera de las carcasas

Sí, pero ¿no podría un shell realizar el análisis por sí mismo si la llamada al sistema devolvió ENOEXEC ? Me doy cuenta de que podría ser una lata de gusanos ...

Dato interesante: la funcionalidad del kernel en Linux parece haber sido escrita por Martin von Löwis, un veterano autor de Python :-)

Esta página también fue una lectura interesante: http://www.in-ulm.de/~mascheck/various/shebang/

Sí, pero ¿no podría un shell realizar el análisis por sí mismo si la llamada al sistema devolvió ENOEXEC ?

En mi opinión, la diferente semántica entre shells y el kernel subyacente generaría mucha confusión tanto para los usuarios como para los desarrolladores. Actualmente, al menos bash y zsh analizan cuando execve () falla, pero solo para un mejor informe de errores, sin proporcionar un respaldo.

Dato interesante: la funcionalidad del kernel en Linux parece haber sido escrita por Martin von Löwis, un veterano autor de Python :-)

¡Interesante! No me di cuenta de eso :) También gracias por el material extra. Si bien leer el código fuente del kernel es la forma más rápida, estos documentos siguen siendo útiles.

Acerca de la idea de @fbidu :

Quizás deberíamos prohibir la creación de un entorno virtual con espacios en el camino. No funcionará como se esperaba de todos modos

La creación de entornos virtuales con rutas frágiles es útil para probar casos de esquina en el manejo de rutas. En este ejemplo, demuestra cómo se rompen los núcleos. Mi idea es agregar advertencias en lugar de prohibir, al igual que el parche que publiqué en http://bugs.python.org/issue28446

Creo que el número 994 "Pip falla con espacio en la ruta virtualenv" es un duplicado de este problema.

Quiero repetir el comentario de https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253, "virtualenv se rompe con el frágil análisis de shebang del kernel". Y en ese espíritu, # 1014 "No es compatible con un directorio que tiene emojis en su camino" es otro ejemplo de virtualenv roto por el frágil análisis de shebang del kernel. Apuesto a que el problema ocurre con cualquier carácter no ASCII en la ruta, de hecho.

¿Quizás deberíamos recopilar los tres aspectos del análisis de shebang del kernel frágil en un solo problema, para que podamos estar seguros de que una solución puede abordar espacios, longitudes y caracteres no ASCII en la ruta virtualenv? Nomino este número porque es el más antiguo.

Mientras trabajamos en una solución, creo que sería bueno que virtualenv imprima una advertencia cuando se le pida que cree un entorno en una ruta que a) tiene espacios, b) es demasiado larga, oc) tiene caracteres que no son ASCII. Una oración en alguna documentación también ayudaría.

Apuesto a que el problema ocurre con cualquier carácter no ASCII en la ruta, de hecho.

Creo que la razón del # 1014 está en virtualenv en lugar del kernel. Tengo un parche que soluciona un problema bastante similar en el # 900.

Hola a todos,
Esto es súper molesto y una enorme pérdida de tiempo debido a algo aparentemente tan simple (al menos una causa simple).

¿Qué tal cambiar el nombre (cuando sea posible) o usar enlaces (crear un directorio como /virtualenvs/python3.5 sin espacio y luego dejar que este sea un enlace suave al directorio original?)

creando un directorio como /virtualenvs/python3.5 sin espacio

Otro proyecto virtualenvwrapper ha hecho algo bastante similar.

algo aparentemente tan simple (causa simple al menos).

Tampoco son simples. La causa está relacionada con los códigos de análisis del kernel y una solución requiere el manejo de shebang del espacio del usuario.

¿Sigue siendo un problema 6 años después?

Este problema me hizo tropezar hace 2 semanas. Sí, sigue siendo un problema.

Tenga en cuenta que como es un problema de Unix en lugar de un problema de virtualenv, es poco probable que se "arregle" a menos que se elimine la limitación del kernel de Unix ...

El primer error de virtualenv es que virtualenv eligió implementar archivos ejecutables de shell mediante el uso de una determinada característica del kernel de Unix, a pesar de que esa característica tiene limitaciones que habitualmente causan problemas al usuario de virtualenv. Virtualenv podría solucionar este problema utilizando un mecanismo diferente para archivos ejecutables de shell. El segundo error de virtualenv es no tener documentación de cómo los usuarios deben usar virtualenv para evitar el primer error (cree un virtualenv solo en rutas cortas con caracteres solo ASCII y sin espacios en blanco). El tercer error de virtualenv es que no tiene un mecanismo que detecte los casos en los que el usuario elige una ruta de virtualenv que desencadenará el primer error e imprimirá un mensaje de advertencia útil. Hay muchas cosas que los contribuyentes virtualenv podrían hacer para mejorar la situación.

@JDLH Acerca de su primer "error": no lo maneja virtualenv sino distlib, y hay una implementación en https://bitbucket.org/pypa/distlib/pull-requests/31/. Espero poder tener tiempo para estudiar los aspectos internos de distlib y responder a los comentarios de Vinay Sajip correctamente, pero desafortunadamente no es así.

El primer error de virtualenv es que virtualenv eligió implementar archivos ejecutables de shell mediante el uso de una determinada función del kernel de Unix

@JDLH Esto no es específico de virtualenv - _todos_ los archivos de script Unix (es decir, archivos con líneas shebang) usan esta función del kernel, y no hay una razón convincente para que virtualenv (o cualquier otra cosa) se reinvente un método completamente nuevo para enviar scripts, cuando el mecanismo existente es tan ampliamente utilizado y bien entendido. Si escribiera un script a mano que tuviera espacios en la ruta del intérprete (sin virtualenv involucrados), presentaría el mismo problema.

Hay muchas cosas que los contribuyentes virtualenv podrían hacer para mejorar la situación.

Probablemente haya muchas llamadas sobre el tiempo de los contribuyentes. Este problema afecta al número relativamente pequeño de casos en los que se utilizan trayectos largos / trayectos con espacios. ¿Quizás algunos de esos usuarios afectados podrían ayudar a los contribuyentes a ayudarlos proponiendo un parche que ayudaría con los mensajes de detección y advertencia? Solo una idea.

@ yan12125 distlib permite especificar el ejecutable en la línea shebang como se desee. La limitación del kernel en espacios en blanco / líneas largas quizás nunca sea corregida por los desarrolladores de Linux debido a la compatibilidad con versiones anteriores. Uno podría simplemente proporcionar una cadena personalizada para el ejecutable shebang (incorporando un equivalente generalizado al truco de script de Mozilla) y distlib debería escribirlo en el script, por lo que uno puede experimentar con él como distlib usuario (por lo tanto, sin _necesidad_ de mirar el interior, AFAICT).

Esto no es específico de virtualenv

@vsajip Esta es una afirmación verdadera - otro software usa el mismo mecanismo de shebang que eligió virtualenv - pero no capta el sentido de este problema. No hay nada en el valor proporcionado por virtualenv que exija que use el shebang. virtualenv podría usar un mecanismo diferente, pero eligió el shebang y, por lo tanto, virtualenv realmente hereda la limitación del shebang.

no hay ninguna razón convincente para que virtualenv (o cualquier otra cosa) reinvente un método completamente nuevo de enviar scripts

Creo que lo que está diciendo es que los problemas experimentados por las personas que se han encontrado con este problema a lo largo de los años no son "convincentes". Creo que la razón por la que tanta gente encuentra y comenta este tema a lo largo de los años es que encuentran los problemas "convincentes". Ciertamente lo hago.

¿Quizás algunos de esos usuarios afectados podrían ayudar a los contribuyentes a ayudarlos proponiendo un parche que ayudaría con los mensajes de detección y advertencia? Solo una idea.

Elegí la palabra "colaboradores" para incluir tanto a los incondicionales que hacen la mayor parte del trabajo en virtualenv, como a los visitantes como yo que encuentran este problema lo suficientemente convincente como para trabajar en la reducción de su impacto. Es justo decir que quienes consideramos que el problema es convincente deberíamos contribuir con un parche.

Sería útil si los incondicionales que conocen bien el virtualenv pudieran sugerir enfoques prometedores. Si quisiera insertar un mensaje de advertencia para el usuario que escribe virtualenv ~/my\ long\ path\ with\ spaces , ¿dónde debería residir mejor ese código? ¿Existen limitaciones no obvias en un parche de este tipo, que los incondicionales podrían compartir, para eliminar un obstáculo del visitante que trabaja en su primera contribución? ¿Tienen los incondicionales alguna objeción histórica a aceptar tal parche? (Quiero decir, no puedo ser la primera persona que pensó en agregar un mensaje de advertencia. Tiene que haber una razón por la que aún no ha sucedido).

Hay una ruta conocida que contiene espacios y no se puede modificar: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs . Entonces, cualquiera que quiera mantener algunos scripts administrados con virtualenv en iCloud se encuentra con este problema.

Sería útil si los incondicionales que conocen bien el virtualenv pudieran sugerir enfoques prometedores.

Bueno, si supiéramos alguna, probablemente no hubiéramos dejado este problema sin resolver durante tanto tiempo, dada la cantidad de críticas que parece que recibimos por hacerlo :-(

Si quisiera insertar un mensaje de advertencia para el usuario que escribe virtualenv ~ / my \ long \ path \ with \ spaces, ¿dónde debería residir mejor ese código?

Puede comenzar mirando el código de análisis del argumento, agregando una marca una vez que se haya determinado la ruta.

¿Existen limitaciones no obvias en un parche de este tipo, que los incondicionales podrían compartir, para eliminar un obstáculo del visitante que trabaja en su primera contribución?

En su mayoría se pueden encontrar buscando en la lista de tema aquí por las diversas observaciones formuladas sobre este y otros temas en los últimos años, pero para empezar, es necesario no rechazar caminos cuándo van a trabajar - y que los medios elaboración de lo que las limitaciones del sistema operativo impone. Estos varían drásticamente entre sistemas. Windows permite espacios y nombres de archivo largos, algunos sistemas Unix permiten espacios, algunos necesitan rutas con espacios entre comillas, algunos tienen límites de longitud muy cortos (¿32 caracteres?), Algunos más largos, ... Muchas limitaciones no están bien documentadas y muy pocas los colaboradores tienen acceso a suficientes sistemas para poder probar todas las posibilidades suficientes para complementar los documentos disponibles.

¿Tienen los incondicionales alguna objeción histórica a aceptar tal parche?

No, aparte de "no asuma que es tan simple como piensa a primera vista, y no ignore todos los diversos (a veces bastante oscuros) sistemas que tenemos que admitir".

Si alguien quiere tomar una puñalada en esto - y ellos deben ser conscientes de que no es algo que yo personalmente recomiendo como una "primera contribución" - entonces deben empezar por leer toda la historia disponible en los diversos temas (algunos vinculado desde este, otros probablemente no, algunos probablemente en el rastreador de pip y tal vez incluso en los rastreadores distlib o setuptools) y resumir en un nuevo PR las restricciones impuestas por varios sistemas operativos. Proponga que como un parche de documentación que dice "a menos que se cumplan estas condiciones, los encabezados shebang usados ​​por virtualenv no funcionarán como se esperaba, por lo que virtualenv no admite la creación de entornos en directorios que no coincidan con las condiciones establecidas". El RP puede incluir un cambio de código para advertir si no se cumplen las condiciones documentadas, o puede proponer esto como trabajo futuro (por lo que recuerdo, es bastante difícil introspectar los detalles del sistema con la suficiente precisión para saber qué límites se aplican; considere "Ubuntu con un kernel parcheado "...). Personalmente, estaría bien con una advertencia que solo marcara los casos conocidos en los que las cosas fallarían y permanecía en silencio si no estaba seguro. Pero también estaría bien con un parche solo para documentos en esta etapa.

Luego, necesitaría obtener revisiones de su parche de personas con acceso a los sistemas que cubre; como se señaló, los desarrolladores principales realmente no pueden ayudar aquí porque ninguno de nosotros usa (por ejemplo) FreeBSD, OpenBSD o Solaris, o ...

También puede hacer un trabajo parcial y crear un PR que agregue documentos y una advertencia solo para (digamos) OSX. No sé si eso detendría las quejas sobre este problema (no tengo idea de qué sistemas surgen con más frecuencia) pero tal vez sería suficiente. Posiblemente uno de los desarrolladores principales que usa OSX estaría de acuerdo con la fusión.

¿Eso ayuda?

Quizás no entiendo algo, pero ¿no podría resolverse este problema con (por ejemplo) bin/pip contener

#!/bin/sh
"/my/long path/with spaces/pythonx.y" "/path/to/my project/with spaces/venv/bin/real-pip" "$@"

y luego mover el script actual pip a real-pip ? No veo por qué tenemos que usar el shebang directamente.

@ raxod502 Supongo que es consciente de que esto no funcionaría en Windows. Además, creo que el encantamiento "normal" necesario en la segunda línea es más complejo que el que das (aunque no sé por qué, personalmente). Probablemente pueda encontrar el enfoque adecuado mediante una búsqueda en la web. Con su enfoque, ¿qué pasaría con las rutas con los caracteres " o $ ?

Suponiendo que pueda abordar este tipo de problemas, supongo que el siguiente paso sería que envíe un PR (según los comentarios anteriores) y podemos debatir los detalles al respecto. Necesitaría involucrar al menos a uno de los confirmadores principales de virtualenv que trabaja en Unix; como usuario de Windows, no estaría dispuesto a fusionar un PR específico de Unix como este.

@pfmoore
La solución propuesta por @ raxod502 también podría funcionar en Windows con un archivo de script .bat, ¿afaik?

@gst Respuesta corta, no. La respuesta larga está en http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html Ha habido muchas discusiones sobre este punto a lo largo de los años, y cada vez que alguien ha encontrado una solución que no sea ​​una exe, ha tenido problemas.

En este caso, recuerde que este problema no existe en Windows . Por lo tanto, no hay absolutamente ninguna razón para cambiar nada en el entorno de Windows; cualquier cambio debe restringirse solo a Unix.

gracias por una buena respuesta :)

que no sea un contenedor exe, ha tenido problemas.

personalmente puedo vivir con eso (si tuviera que hacerlo).

Actualicé distlib para manejar rutas largas y rutas con espacios. No utilicé el parche de Harald Nordgren directamente (tenía algunos problemas, por ejemplo, sin pruebas) pero el enfoque es el mismo: usando '/ bin / sh' como ejecutable. pip mantenedores de virtualenv pueden querer probar después de vender localmente la versión actual del repositorio distlib .

La versión de desarrollo de pip ahora ofrece esta nueva versión de distlib, lo que significa que pip ahora maneja espacios en los nombres de directorio sin problemas.

Según tengo entendido, una vez que se realice la próxima versión de pip y una versión virtualenv, este problema se solucionará: cualquier nuevo virtualenv creado admitirá espacios en la ruta, al igual que los binarios instalados por pip (excepto posiblemente en algunos casos extravagantes como setuptools 'envoltorios que no son instalados directamente por pip).

Acabo de comenzar a usar gvfs para montar recursos compartidos de samba en el espacio de usuario y encontrar virtualenv / pip, etc., estropeado debido a la puntuación en las rutas de montaje generadas por gvfs.

No hay espacios en las rutas, pero hay muchas otras cosas para poner virtualenv / pip, etc. de rodillas tratando de correr en un directorio como

/run/user/1000/gvfs/smb-share:server=bolt,share=eng/projects/msp/mrfbus/land

Por lo que puedo ver, actualmente no hay ninguna opción en gvfs para evitar la puntuación en las rutas de sus puntos de montaje generados. Mi única solución es nunca crear un virtualenv en un montaje de gvfs, lo que parece un poco triste

@pradyunsg ¿Hay algún cronograma para el próximo lanzamiento de pip? El último fue hace más de un año , y parece un poco tonto esperar tanto tiempo para que aparezca esta solución realmente simple en virtualenv.

¡Hola @ raxod502!

Sí, queremos sacarlo pronto. La cuestión es que tenemos poco tiempo de desarrollador para sacar PEP 518, que es algo que queremos hacer. Puede suceder que haya un pip 10 sin PEP 518, pero nuevamente, depende de encontrar el tiempo para establecer el plan en eso.

Parece que este error se corrigió con pip 10.0.0 , lanzado 2018-04-14. Estrictamente hablando, la solución estaba en distlib 0.2.6 , que se vendió en pip con su PR4819 en octubre de 2017, que apareció por primera vez en pip 10.0.0b2.

La solución subyacente parece estar en el compromiso 9285cca de distlib . Como vsajip comentó aquí el 28 de mayo de 2017 , el enfoque sigue la idea de Harald Nordgren: siga usando un shebang simple para casos simples (el sistema operativo no es Posix, o la ruta es lo suficientemente corta y no tiene espacios), pero para los casos no simples, use un comando /bin/sh exec lugar, que puede manejar las rutas largas o que contienen espacios.

Hice una prueba rápida en Mac OS X 10.11.6, creando un entorno virtual en una ruta larga con espacios, luego invocando pip3 install , y parece que funciona. No he probado completamente que todo lo descrito en este error esté arreglado en todos los sistemas operativos.

Después de actualizar pip de 9.0.1 a 18.1 (cambiaron a la versión basada en calendario) y virtualenv de 15.0.1 a 16.0.0 usando Ubuntu 16.04.5 LTS, el problema parece haber desaparecido:

sudo pip install --upgrade pip
sudo pip install --upgrade virtualenv

Ahora todos los comandos pip funcionan correctamente en virtualenvs que tienen espacios en su ruta raíz.

Como lo confirmaron @JLDH y @gandie , este problema ya se ha resuelto; con las últimas versiones de pip y virtualenv juntas funcionando correctamente cuando la raíz de un virtualenv tiene espacios.

¡Cerrando esto! ¡Gracias por el trabajo en la solución subyacente @vsajip!

Billete antiguo: pero por qué no

! / usr / bin / env python?

@rirl , creo que es poco probable que dejar un comentario sobre un problema cerrado