+1, confirmado com Mac OS X 10.7.3 e Python 2.7.1

Meio irritante, seria ótimo ter uma solução

Somos capazes de criar um virtualenv com espaços no nome (veja # 278), mas easy_install e pip tropeçam nisso mais 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

Também estou aqui para confirmar que este é um problema com o OS X (10.8 aqui). Se você editar a variável VIRTUAL_ENV e inserir no bin, poderá fazê-lo funcionar, mas um novo env bloqueia quaisquer espaços em um caminho. O que é um grande problema para o OS X, visto que a unidade de inicialização é normalmente chamada de "Macintosh HD", então todos os caminhos começam com "/ Volumes / Macintosh HD ..."

O hack que estou usando funciona da seguinte maneira.

bin / ativar:

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

bin / pip e bin / easy_install:

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

Pip parece estar trabalhando depois de escapar do espaço no caminho.

Por que isso foi fechado? Ainda é um grande problema. edite meu erro, ainda está aberto

este problema ainda parece aberto.

Consegui contornar isso criando um link simbólico do meu diretório pessoal para aquele em que eu queria trabalhar (que, de outra forma, tinha um espaço).

Estou vendo isso também porque Mac. Eu consigo contornar isso editando manualmente a linha shebang nos scripts para! # / Usr / bin / env python e tudo funciona. No entanto, como outros mencionaram, isso deve ser feito com cada novo env e quaisquer scripts adicionais instalados no env.
Parece que isso deve ser uma correção fácil no código para escapar do espaço ou usar / usr / bin / env se is_darwin. No entanto, como sou praticamente um novato nisso, posso estar errado.

Isso não é apenas para mac, é basicamente parte da especificação / comportamento dos sistemas * nix.

Você não pode ter espaços no primeiro argumento da linha shebang (eles serão transformados em argumentos separados ao invés), e normalmente não há escape / citação permitido também.

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

Eu sei, eu tive esse problema com a anaconda também. t é endêmico no Mac porque o nome do drive contém um espaço em branco.

Parece que isso seria corrigido por # 611. Houve alguma revisão da eficácia dessa solicitação de pull?

Tão chato, deve ser consertado o mais rápido possível.

Veja o link postado por @Ivoz , esta é uma limitação do Unix. # 611 pode funcionar para algumas variantes do Unix, se elas suportarem escapes de barra invertida em uma linha shebang, mas não está claro quais versões suportam (e o código faz isso cegamente sem verificar - o que certamente não tornará o problema _pior_, mas ganhou ' t ajudar se não for compatível ...)

É verdade que isso é resultado da maneira como o unix lida com linhas simples, mas se o # 611 corrige o problema para alguns sistemas e não piora o problema para outros, isso ainda seria uma melhoria?

Se isso for verdade, sim. Mas não posso comentar sobre o # 611 porque não sou um desenvolvedor Unix. Pode haver casos em que isso torna as coisas piores, simplesmente não sei. Desculpe, não posso ser mais útil.

Justo. # 611 provavelmente precisa ser analisado com mais cuidado e testado para casos marginais.

Pior ainda: no Windows, ele quebra no caminho padrão do Jenkins com o mesmo erro:
FATAL: espaços em branco não são permitidos no caminho do interpretador Python: C: \ Arquivos de programas (x86) \ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41d8cd9

Eu fui afetado por este problema. Seguindo as instruções que encontrei no StackOverflow , consegui fazer pip funcionar apenas definindo a primeira linha como #!/usr/bin/env python

Não tenho certeza, entretanto, se essa solução funciona para todos os casos ... Quer dizer, não tenho certeza sobre qual Python será executado

Alterar o conjunto de scripts instalados para “env python” significa que eles funcionarão apenas em um virtualenv ativado. Os scripts foram gerados com caminhos absolutos explícitos para que sempre usassem o Python no venv e, assim, encontrassem os pacotes instalados necessários para os scripts.

Minha sugestão seria que alguém (provavelmente alguém afetado por este problema, mas no mínimo alguém em uma plataforma que tem o problema e também tem uma maneira de resolvê-lo) forneça uma solicitação pull implementando uma verificação nos seguintes termos:

• Se tivermos espaços no caminho,
• e estamos na plataforma XXX,
• em seguida, escreva a linha shebang com o seguinte escape para lidar com os espaços.
• Em todos os outros casos, volte ao comportamento atual.

Outras adições podem ser feitas pelas partes interessadas, apenas adicionando verificações de plataforma extras.

Idealmente, seria bom incluir um comentário com um link para a documentação que confirma como a plataforma XXX suporta caminhos com espaços, para que os futuros mantenedores tenham uma referência para verificar. Pessoalmente, não tenho certeza de quais correções funcionam e onde:

1. a discussão aqui sugere que as aspas duplas funcionam no OSX, mas isso depende da versão exata do OSX?
2. Em # 611, foram usados ​​espaços de escape com barras invertidas, mas não houve confirmação sobre para qual sistema operacional era (Linux? Uma versão de kernel específica? Uma distro específica?)

Observe que nenhuma dessas variantes específicas da plataforma deve usar /usr/bin/env . Como @merwok apontou, isso resulta em uma mudança no comportamento - o shebang é escrito deliberadamente para permitir a execução do script _sem_ ativar o ambiente.

Adicionar alguns testes para ter certeza de que o comportamento é o esperado (incluindo o princípio de que ocorre quando não estamos em uma plataforma especificamente reconhecida) também seria extremamente útil, mas também seria complicado, pois envolveria o monkeypatching para permitir o teste da plataforma XXX quando não estiver realmente executando nessa plataforma.

@pfmoore Como mencionei, recentemente fui afetado por esse problema e estou executando o Linux Mint 18. Nunca contribuí com a Virtualenv, mas atualmente estou na Python Brasil e teremos um dia dedicado a sprints, posso dar isso uma tentativa!

escapar com barras invertidas ou aspas não funcionará, de acordo com https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html

Experimentalmente, posso verificar que escapar com barras invertidas ou aspas não funciona com o OSX 10.11.6.

virtualenv deve ficar longe de shebangs dependentes de kernel. Verifiquei os códigos-fonte do Linux, XNU (kernel do macOS), FreeBSD, OpenBSD e NetBSD. Nenhum deles pode lidar com espaços em shebang.

Antes que haja uma correção, não use espaços.

Eu envio um patch que adiciona um aviso para o novo venv do Python 3, que é bastante semelhante ao virtualenv, mas rejeitado por @vsajip : http://bugs.python.org/issue28446. Na verdade, não é culpa do Python, mas do sistema operacional. Talvez este problema possa ser resolvido?

Como um ponto de dados extra, observe o comportamento no Windows, que parece ser o esperado:

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

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" - versão
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"
Existe um lançador.
Shebang: #! "C: \ Temp \ aaa bbb \ Scripts \ python.exe"

Conteúdo do arquivo:
__main__.py

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
Você está usando o pip versão 6.0.8, mas a versão 9.0.1 está disponível.
Você deve considerar a atualização por meio do comando 'pip install --upgrade pip'.
Coletando pip em 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 em cache
Instalando pacotes coletados: pip
Instalação existente encontrada: pip 6.0.8
Desinstalando pip-6.0.8:
Pip-6.0.8 desinstalado com sucesso

Pip-9.0.1 instalado com sucesso

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" - versão
pip 9.0.1 de C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)
`` `

Sim, os scripts do virtualenv no Windows funcionam enquanto distlib define seu próprio protocolo shebang em PC / launcher.c. Talvez POSIX possa ter algo semelhante - um analisador de espaço do usuário shebang em vez de kernels não confiáveis.

um analisador shebang do espaço do usuário em vez de kernels não confiáveis

Não sei por que o Bash não pode fazer isso (por exemplo) - não acho que seja uma coisa do espaço do kernel.

Shebangs são tratados no espaço do kernel porque devem ser utilizáveis ​​fora de shells.

Detalhes técnicos:
Em sistemas semelhantes ao UNIX (Linux, Mac, * BSD, ...), um novo programa é criado por meio de fork () e exec (). exec () é semelhante a CreateProcess () no Windows, que executa um novo programa. Em sistemas semelhantes ao UNIX, exec () eventualmente chama a chamada de sistema execve (). A última função é implementada em kernels, portanto, a análise básica é feita em kernels.
Também não pode ser implementado em bibliotecas C, ou programas vinculados estáticos ou programas que usam chamadas de sistema diretamente (via int 80 ou sysenter, etc.) não funcionarão.

Talvez devêssemos apenas proibir a criação de um ambiente virtual com espaços no caminho. Não funcionará como esperado de qualquer maneira

Shebangs são tratados no espaço do kernel porque devem ser utilizáveis ​​fora de shells

Sim, mas um shell não poderia fazer a análise se a chamada do sistema retornasse ENOEXEC ? Sei que pode ser uma lata de vermes ...

Boato interessante - a funcionalidade do kernel no Linux parece ter sido escrita pelo committer Python de longa data, Martin von Löwis :-)

Esta página também foi uma leitura interessante: http://www.in-ulm.de/~mascheck/various/shebang/

Sim, mas um shell não poderia fazer a análise se a chamada do sistema retornasse ENOEXEC ?

Semânticas diferentes da IMO entre os shells e o kernel subjacente trariam muita confusão para os usuários e também para os desenvolvedores. Atualmente, pelo menos bash e zsh fazem a análise quando execve () falha, mas apenas para um melhor relatório de erros, não fornecendo um fallback.

Boato interessante - a funcionalidade do kernel no Linux parece ter sido escrita pelo committer Python de longa data, Martin von Löwis :-)

Interessante! Eu não percebi isso :) Obrigado também pelo material extra. Embora a leitura do código-fonte do kernel seja a maneira mais rápida, esses documentos ainda são úteis.

Sobre a ideia de @fbidu :

Talvez devêssemos apenas proibir a criação de um ambiente virtual com espaços no caminho. Não funcionará como esperado de qualquer maneira

A criação de ambientes virtuais com caminhos frágeis é útil para testar casos extremos no tratamento de caminhos. Neste exemplo, ele demonstra como os kernels são quebrados. Minha ideia é adicionar avisos em vez de proibir, assim como o patch que postei em http://bugs.python.org/issue28446

Eu acho que # 994 "Pip falha com espaço no caminho virtualenv" é uma duplicata deste problema.

Quero repetir o comentário de https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253, "virtualenv está quebrado com análise shebang de kernel frágil." E com esse espírito, # 1014 "Não compatível com um diretório com emojis em seu caminho" é outro exemplo de virtualenv sendo quebrado por uma análise simples do kernel frágil. Aposto que o problema ocorre com qualquer caractere não ASCII no caminho, na verdade.

Talvez devêssemos reunir todos os três aspectos da análise shebang do kernel frágil em um único problema, para que possamos ter certeza de que uma correção pode endereçar espaços, comprimento e caracteres não ASCII no caminho virtualenv. Eu indico esse problema, porque é o mais antigo.

Enquanto trabalhamos em uma correção, acho que seria bom para o virtualenv imprimir um aviso quando solicitado a criar um ambiente em um caminho que a) contenha espaços, b) seja muito longo ou c) contenha caracteres não ASCII. Uma frase em alguma documentação também ajudaria.

Aposto que o problema ocorre com qualquer caractere não ASCII no caminho, na verdade.

Acredito que o motivo do # 1014 esteja no virtualenv e não no kernel. Eu tenho um patch que corrige um problema bastante semelhante em # 900.

Olá a todos,
Isso é super irritante e uma enorme perda de tempo devido a algo aparentemente tão simples (pelo menos uma causa simples).

Que tal renomear (quando possível) ou usar links (criar um diretório como /virtualenvs/python3.5 sem espaço e, em seguida, deixar que seja um link virtual para o diretório original?)

criando um diretório como /virtualenvs/python3.5 sem espaço

Outro projeto virtualenvwrapper fez algo bastante semelhante.

algo aparentemente tão simples (pelo menos uma causa simples).

Nem são simples. A causa está relacionada aos códigos de análise do kernel e uma solução alternativa requer manipulação completa do espaço do usuário.

Ainda é um problema 6 anos depois?

Este problema me fez tropeçar há 2 semanas. Sim, ainda é um problema.

Observe que, como é um problema do Unix em vez de um problema do virtualenv, é improvável que seja "corrigido" a menos que a limitação do kernel do Unix seja removida ...

O primeiro bug do virtualenv é que o virtualenv optou por implementar arquivos executáveis ​​em shell usando um determinado recurso do kernel do Unix, apesar desse recurso ter limitações que costumam causar problemas para o usuário do virtualenv. A Virtualenv pode corrigir isso usando um mecanismo diferente para arquivos executáveis ​​em shell. O segundo bug do virtualenv é não ter documentação de como os usuários devem usar o virtualenv para contornar o primeiro bug (crie um virtualenv apenas em caminhos curtos com caracteres somente ASCII e sem espaços em branco). O terceiro bug do virtualenv é que ele não possui mecanismo que detecta casos em que o usuário escolhe um caminho do virtualenv que irá acionar o primeiro bug e imprimir uma mensagem de aviso útil. Os colaboradores do virtualenv podem fazer muitas coisas para melhorar a situação.

@JDLH Sobre o seu primeiro "bug": não é tratado pelo virtualenv, mas pela distlib, e há uma implementação em https://bitbucket.org/pypa/distlib/pull-requests/31/. Espero ter tempo para estudar os detalhes internos da distlib e responder aos comentários de Vinay Sajip de maneira adequada, mas infelizmente não tenho.

O primeiro bug do virtualenv é que o virtualenv escolheu implementar arquivos executáveis ​​em shell usando um determinado recurso do kernel Unix

@JDLH Isso não é específico para virtualenv - _todos_ os arquivos de script Unix (ou seja, arquivos com linhas shebang) usam este recurso do kernel - e não há razão convincente para virtualenv (ou qualquer outra coisa) reinventar um método completamente novo de despacho de scripts, quando o mecanismo existente é tão amplamente usado e bem compreendido. Se você escreveu um script à mão com espaços no caminho do interpretador (sem virtualenv envolvido), ele apresentaria o mesmo problema.

Os colaboradores do virtualenv podem fazer muitas coisas para melhorar a situação.

Provavelmente, há muitas chamadas no tempo dos colaboradores. Esse problema afeta o número relativamente pequeno de casos em que caminhos longos / caminhos com espaços são usados. Talvez alguns dos usuários afetados possam ajudar os contribuidores a ajudá-los, propondo um patch que ajudará na detecção e nas mensagens de aviso. Apenas uma ideia.

@ yan12125 distlib permite especificar o executável na linha shebang como quiser. A limitação do kernel em espaços em branco / linhas longas talvez nunca seja corrigida pelos desenvolvedores Linux por causa da compatibilidade com versões anteriores. Pode-se apenas fornecer uma string personalizada para o executável shebang (incorporando um equivalente generalizado ao hack do script Mozilla) e distlib deve escrevê-lo no script, para que possa experimentá-lo apenas como distlib user (portanto, sem _necessidade_ de olhar para os internos, AFAICT).

Isso não é específico para virtualenv

@vsajip Esta é uma afirmação verdadeira - outro software usa o mesmo mecanismo que o virtualenv escolheu - mas não entende o ponto principal. Não há nada sobre o valor fornecido pelo virtualenv que exija o uso do shebang. O virtualenv poderia usar um mecanismo diferente, mas escolheu o shebang e, portanto, o virtualenv realmente herda a limitação do shebang.

não há razão convincente para o virtualenv (ou qualquer outra coisa) reinventar um método completamente novo de envio de scripts

Acho que o que você está dizendo é que os problemas experimentados pelas pessoas que encontraram esse problema ao longo dos anos não são "convincentes". Acho que a razão pela qual tantas pessoas descobrem e comentam sobre essa questão ao longo dos anos é que elas consideram os problemas "convincentes". Eu certamente faço.

Talvez alguns dos usuários afetados possam ajudar os contribuidores a ajudá-los, propondo um patch que ajudará na detecção e nas mensagens de aviso. Apenas uma ideia.

Escolhi a palavra "contribuidores" para incluir os partidários que fazem a maior parte do trabalho no virtualenv e os visitantes como eu, que consideram esse problema atraente o suficiente para trabalhar na redução de seu impacto. É justo dizer que nós, que achamos o problema atraente, devemos contribuir com um patch.

Seria útil se os partidários que conhecem bem o virtualenv pudessem sugerir abordagens promissoras. Se eu quisesse inserir uma mensagem de aviso para o usuário que digitar virtualenv ~/my\ long\ path\ with\ spaces , onde esse código deveria residir melhor? Existem restrições não óbvias em tal patch, que os partidários poderiam compartilhar, para remover um obstáculo do visitante que está trabalhando em sua primeira contribuição? Os partidários têm alguma objeção histórica em aceitar tal patch? (Quer dizer, não posso ser a primeira pessoa a pensar em adicionar uma mensagem de aviso. Deve haver um motivo para isso ainda não ter acontecido.)

Existe um caminho conhecido que contém espaços e não pode ser modificado: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs . Portanto, qualquer pessoa que queira manter alguns scripts gerenciados com virtualenv no iCloud se depara com esse problema.

Seria útil se os partidários que conhecem bem o virtualenv pudessem sugerir abordagens promissoras.

Bem, se soubéssemos de algum, provavelmente não teríamos deixado esse problema sem solução por tanto tempo, dada a quantidade de críticas que recebemos por isso :-(

Se eu quisesse inserir uma mensagem de aviso para o usuário que digitar virtualenv ~ / my \ long \ path \ com \ espaços, onde esse código deveria residir melhor?

Você pode começar examinando o código de análise do argumento, adicionando uma verificação assim que o caminho for determinado.

Existem restrições não óbvias em tal patch, que os partidários poderiam compartilhar, para remover um obstáculo do visitante que está trabalhando em sua primeira contribuição?

Eles podem ser encontrados principalmente pesquisando a lista de problemas aqui para os vários comentários feitos sobre este e outros problemas ao longo dos anos, mas para começar, você não precisa rejeitar caminhos quando eles funcionarão - e isso significa descobrir quais são as limitações do sistema operacional impõe. Eles variam drasticamente entre os sistemas. O Windows permite espaços e nomes de arquivos longos, alguns sistemas Unix permitem espaços, alguns precisam de caminhos com espaços para serem citados, alguns têm limites de comprimento muito curtos (32 caracteres?), Outros mais, ... Muitas limitações não estão bem documentadas, e muito poucas os contribuidores têm acesso a sistemas suficientes para poder testar todas as possibilidades suficientes para complementar os documentos disponíveis.

Os partidários têm alguma objeção histórica em aceitar tal patch?

Não, exceto "não presuma que é tão simples quanto você pensa à primeira vista, e não ignore todos os vários sistemas (às vezes muito obscuros) que temos que oferecer suporte".

Se alguém quiser tomar uma facada em isso - e eles devem estar cientes de que não é algo que eu, pessoalmente, recomendo como uma "primeira contribuição" - então eles devem começar por ler toda a história disponível nos vários problemas (alguns vinculados a este, outros provavelmente não, alguns provavelmente no rastreador de pip e talvez até mesmo nos rastreadores distlib ou setuptools) e resumir em um novo PR as restrições impostas por vários sistemas operacionais. Proponha que como um patch de documentação que afirma "a menos que essas condições sejam atendidas, os cabeçalhos shebang usados ​​pelo virtualenv não funcionarão como esperado e, portanto, o virtualenv não suporta a criação de ambientes em diretórios que não correspondam às condições declaradas". O PR pode incluir uma mudança de código para avisar se as condições documentadas não forem atendidas, ou pode propor isso como um trabalho futuro (pelo que me lembro, é muito difícil introspectar os detalhes do sistema com precisão suficiente para saber quais limites se aplicam - considere "Ubuntu com um kernel corrigido "...). Pessoalmente, ficaria bem com um aviso que sinalizasse apenas casos conhecidos em que as coisas iriam falhar e ficaria em silêncio se não tivesse certeza. Mas eu também estaria bem com um patch somente para documentos neste estágio.

Você então precisaria obter revisões de seu patch de pessoas com acesso aos sistemas que você cobre - como observado, os desenvolvedores principais não podem realmente ajudar aqui porque nenhum de nós usa (por exemplo) FreeBSD, ou OpenBSD, ou Solaris, ou ...

Você também pode apenas fazer um trabalho parcial e criar um PR que adiciona documentos e um aviso apenas para (digamos) OSX. Não sei se isso acabaria com as reclamações sobre esse problema (não tenho uma ideia de quais sistemas isso surge com mais frequência), mas talvez fosse suficiente. Possivelmente, um dos desenvolvedores principais que usa OSX aceitaria mesclar isso.

Isso ajuda?

Talvez eu não entenda algo, mas esse problema não poderia ser resolvido tendo (por exemplo) bin/pip contido

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

e, em seguida, movendo-se a corrente pip script para real-pip ? Não vejo por que temos que usar o shebang diretamente.

@ raxod502 Suponho que você saiba que isso não funcionaria no Windows. Além disso, acho que o encantamento "normal" necessário na segunda linha é mais complexo do que o que você dá (embora eu não saiba por que, pessoalmente). Provavelmente, você pode encontrar a abordagem adequada por meio de uma pesquisa na web. Com sua abordagem, o que aconteceria para caminhos com " ou $ caracteres neles?

Supondo que você possa resolver esse tipo de questão, acho que a próxima etapa seria você enviar um PR (conforme os comentários acima) e podemos debater os detalhes sobre isso. Você precisaria ter pelo menos um dos committers do virtualenv core que trabalha no Unix envolvido - como um usuário do Windows, eu não estaria disposto a mesclar um PR específico do Unix como este.

@pfmoore
a solução proposta por @ raxod502 também pode funcionar no Windows com um arquivo de script .bat, afaik?

@gst Resposta curta, não. A resposta longa está em http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html Tem havido muitas discussões sobre esse ponto ao longo dos anos, e toda vez que alguém surge com uma solução diferente de um invólucro exe, ele teve problemas.

Neste caso, lembre-se de que este problema não existe no Windows . Portanto, não há absolutamente nenhuma razão para alterar nada no ambiente do Windows - qualquer alteração deve ser restrita apenas ao Unix.

obrigado pela boa resposta :)

além de um invólucro exe, teve problemas.

pessoalmente posso viver com isso (se eu tivesse que).

Eu atualizei distlib para lidar com caminhos longos e caminhos com espaços. Não usei o patch de Harald Nordgren diretamente (ele teve alguns problemas - por exemplo, nenhum teste), mas a abordagem é a mesma - usando '/ bin / sh' como o executável. pip / virtualenv mantenedores podem querer testar depois de vender localmente a versão atual do repositório distlib .

A versão de desenvolvimento do pip agora fornece esta versão mais recente do distlib, o que significa que o pip agora lida muito bem com espaços em nomes de diretório.

Pelo que entendi, assim que a próxima versão do pip e uma versão do virtualenv forem feitas, esse problema será corrigido - qualquer novo virtualenv criado oferecerá suporte a espaços no caminho, assim como os binários instalados pelo pip (exceto possivelmente em alguns casos peculiares como ferramentas de configuração 'wrappers que não são instalados diretamente pelo pip).

Acabei de começar a usar o gvfs para montar compartilhamentos do samba no espaço do usuário e encontrar virtualenv / pip etc. danificado por conta de puncionalidade nos caminhos de montagem gerados pelo gvfs.

Não há espaços nos caminhos, mas muitas outras coisas para colocar o virtualenv / pip etc de joelhos tentando correr em um dir como

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

Pelo que eu posso ver, não há nenhuma opção atualmente no gvfs para evitar pontuação nos caminhos de seus pontos de montagem gerados. Minha única solução é nunca criar um virtualenv em uma montagem gvfs, o que parece um pouco triste

@pradyunsg Existe algum cronograma para o próximo lançamento do pip? O último foi há mais de um ano , e parece meio idiota esperar tanto para que essa solução realmente simples apareça no virtualenv.

Olá @ raxod502!

Sim, queremos lançá-lo logo. O problema é que temos pouco tempo de desenvolvedor para lançar o PEP 518, que é algo que queremos fazer. Pode acontecer que haja um pip 10 sem PEP 518, mas, novamente, depende de encontrar tempo para definir o plano sobre isso.

Parece que esse bug foi corrigido pelo pip 10.0.0 , lançado em 14/04/2018. Estritamente falando, a correção estava no distlib 0.2.6 , que foi vendido no pip com seu PR4819 em outubro de 2017, que apareceu pela primeira vez no pip 10.0.0b2.

A correção subjacente parece estar no commit 9285cca da distlib . Como vsajip comentou aqui em 28 de maio de 2017 , a abordagem segue a ideia de Harald Nordgren: continue usando um shebang simples para casos simples (OS não é Posix ou o caminho é curto o suficiente e não tem espaços), mas para casos não simples, use um comando /bin/sh exec vez disso, que pode manipular os caminhos longos ou que contêm espaço.

Fiz um teste rápido no Mac OS X 10.11.6, criando um env virtual em um longo caminho com espaços, em seguida invocando pip3 install , e parece funcionar. Não testei totalmente se tudo descrito neste bug foi corrigido em todos os sistemas operacionais.

Depois de atualizar o pip de 9.0.1 para 18.1 (eles mudaram para a versão baseada em calendário) e o virtualenv de 15.0.1 para 16.0.0 usando Ubuntu 16.04.5 LTS, o problema parece ter desaparecido:

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

Agora todos os comandos pip funcionam corretamente no virtualenvs com espaços em seu caminho raiz.

Conforme confirmado por @JLDH e @gandie , esse problema foi resolvido; com as versões mais recentes de pip e virtualenv juntas funcionando corretamente quando a raiz de um virtualenv contém espaços.

Fechando isso! Obrigado pelo trabalho na correção subjacente @vsajip!

Bilhete antigo: mas por que não

! / usr / bin / env python?

@rirl , acho que deixar um comentário sobre um problema encerrado dificilmente