+1, Mac OS X 10.7.3 및 Python 2.7.1에서 확인

좀 짜증나고, 수정하면 좋을 것입니다.

이름에 공백이있는 virtualenv를 만들 수 있지만 (# 278 참조), 나중에 easy_install과 pip가 우연히 발견됩니다.

% 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

나는 또한 이것이 OS X (여기 10.8)의 문제임을 확인하기 위해 여기에 있습니다. VIRTUAL_ENV 변수와 bin의 shebangs를 편집하면 작동하도록 할 수 있지만 새로운 env는 경로의 모든 공간에서 질식합니다. 부팅 드라이브의 이름이 일반적으로 "Macintosh HD"이므로 모든 경로가 "/ Volumes / Macintosh HD ..."로 시작한다는 점을 감안할 때 OS X의 큰 문제입니다.

내가 사용하는 해킹은 다음과 같이 작동합니다.

빈 / 활성화 :

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

bin / pip 및 bin / easy_install :

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

경로의 공간을 탈출 한 후 핍이 작동하는 것 같습니다.

왜 이것이 닫혔습니까? 여전히 매우 문제입니다. 내 실수를 수정 해도 아직 열려있어

이 문제는 여전히 열려 있습니다.

나는 내 홈 디렉토리에서 내가 작업하고 싶은 (그렇지 않으면 공백이있는) 심볼릭 링크를 만드는이 문제를 해결할 수있었습니다.

Mac 때문에 나도 이것을보고 있습니다. 스크립트의 shebang 줄을! # / usr / bin / env python 및 모든 작업으로 수동 편집하여이 문제를 해결합니다. 그러나 다른 사람들이 언급했듯이 이것은 각각의 새로운 env와 env에 설치된 추가 스크립트로 수행되어야합니다.
이것은 공간을 이스케이프하거나 is_darwin 인 경우 / usr / bin / env를 사용하는 코드에서 쉽게 수정해야합니다. 그러나 나는 이것에 대해 거의 멍청이이기 때문에 나는 틀릴 수 있습니다.

이것은 Mac만을위한 것이 아니라 기본적으로 * nix 시스템의 사양 / 동작의 일부입니다.

shebang 줄의 첫 번째 인수에는 공백을 사용할 수 없으며 (대신 별도의 인수로 바뀜) 일반적으로 이스케이프 / 따옴표도 허용되지 않습니다.

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

나는 아나콘다에서도이 문제에 부딪혔다. 드라이브 이름에 공백이 있기 때문에 Mac에서만 발생합니다.

# 611에 의해 수정 된 것 같습니다. 풀 리퀘스트의 효능에 대한 리뷰가 있습니까?

너무 짜증나게, 최대한 빨리 수정해야합니다.

@Ivoz가 게시 한 링크를 참조하십시오. 이것은 Unix 제한 사항입니다. # 611은 shebang 줄에서 백 슬래시 이스케이프를 지원하는 경우 일부 Unix 변형에서 작동 할 수 있지만 어떤 버전이 수행하는지 명확하지 않습니다 (코드는 확인하지 않고 맹목적으로 수행합니다. 지원되지 않는 경우 도움이됩니다 ...)

이것이 유닉스가 shebang 라인을 처리하는 방식의 결과라는 것은 사실이지만, # 611이 일부 시스템의 문제를 해결하고 다른 시스템의 문제를 악화시키지 않으면 여전히 개선이 될까요?

그것이 사실이라면 그렇습니다. 하지만 저는 유닉스 개발자가 아니기 때문에 # 611에 대해 언급 할 수 없습니다. 상황을 악화시키는 경우가있을 수 있습니다. 더 이상 도와 드릴 수 없어서 죄송합니다.

그럴 수 있지. # 611은 아마도 더 신중하게 살펴보고 프린지 케이스에 대해 테스트해야 할 것입니다.

더 나쁜 것은 Windows에서 동일한 오류로 기본 Jenkins 경로에서 중단됩니다.
치명적 : Python 인터프리터 경로에 공백이 허용되지 않습니다. C : Program Files (x86) Jenkinsshiningpandajobsc3418983virtualenvsd41d8cd9

이 문제의 영향을 받았습니다. StackOverflow 에서 찾은 지침 #!/usr/bin/env python 설정하여 pip 작동하도록 관리했습니다.

그러나이 솔루션이 모든 경우에 작동하는지 확실하지 않습니다. 어떤 Python이 실행 될지 확실하지 않습니다.

설치된 스크립트의 shebang을 "env python"으로 변경하면 활성화 된 virtualenv에서만 작동합니다. 스크립트는 명시 적 절대 경로로 생성되어 항상 venv에서 Python을 사용하므로 스크립트에 필요한 설치된 패키지를 찾습니다.

내 제안은 누군가 (아마도이 ​​문제의 영향을받는 사람이지만 최소한 문제가 있고 해결 방법이있는 플랫폼의 누군가)이 다음과 같은 라인을 따라 확인을 구현하는 풀 요청을 제공하는 것입니다.

• 경로 이름에 공백이 있으면
• 우리는 플랫폼 XXX에 있습니다.
• 그런 다음 공백을 처리하기 위해 다음 이스케이프와 함께 shebang 줄을 작성하십시오.
• 다른 모든 경우에는 현재 동작으로 돌아갑니다.

추가 플랫폼 확인을 추가하기 만하면 이해 당사자가 추가로 추가 할 수 있습니다.

이상적으로는 플랫폼 XXX가 공백이있는 경로를 지원하는 방법을 확인하는 문서에 대한 링크가있는 주석을 포함하여 향후 관리자가 확인할 참조를 갖게하는 것이 좋습니다. 개인적으로 어떤 수정이 작동하고 어디에 있는지 명확하지 않습니다.

1. 여기서 논의는 큰 따옴표가 OSX에서 작동한다는 것을 암시하지만 정확한 OSX 버전에 따라 달라지는가?
2. # 611에서 백 슬래시가있는 이스케이프 공백이 사용되었지만 어떤 OS인지에 대한 확인은 없었습니다 (Linux? 특정 커널 버전? 특정 배포판?).

이러한 플랫폼 별 변형은 /usr/bin/env 사용해서는 안됩니다. @merwok이 지적했듯이, 그 결과 행동이 변경됩니다. shebang은 환경을 활성화하는 _without_ 스크립트를 실행할 수 있도록 의도적으로 작성되었습니다.

동작이 예상대로 작동하는지 확인하기 위해 몇 가지 테스트를 추가하는 것도 매우 유용 할 것입니다. 실제로 해당 플랫폼에서 실행하지 않을 때 플랫폼 XXX에 대한 테스트를 허용합니다.

@pfmoore 내가 언급했듯이 최근에이 문제의 영향을 받아 Linux Mint 18을 실행하고 있습니다. Virtualenv에 기여한 적이 없지만 현재 Python Brasil에 있으며 스프린트 전용 하루를 보낼 예정입니다. 시도!

https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html 에 따르면 백 슬래시 또는 따옴표로 이스케이프하는 것은 작동하지 않습니다.

실험적으로 백 슬래시 나 따옴표를 사용한 이스케이프가 OSX 10.11.6에서 작동하지 않음을 확인할 수 있습니다.

virtualenv는 커널에 의존하는 shebangs를 멀리해야합니다. Linux, XNU (macOS 커널), FreeBSD, OpenBSD 및 NetBSD 소스 코드를 확인했습니다. 그들 중 누구도 shebang의 공간을 처리 할 수 ​​없습니다.

수정하기 전에 공백을 사용하지 마십시오.

Python 3의 새로운 venv에 대한 경고를 추가하는 패치를 제출합니다. 이는 virtualenv와 매우 유사하지만 @vsajip에 의해 거부되었습니다 : http://bugs.python.org/issue28446. 실제로 그것은 파이썬의 잘못이 아니라 운영 체제의 잘못입니다. 이 문제를 해결할 수 있습니까?

추가 데이터 포인트로 예상대로 보이는 Windows의 동작을 확인하십시오.

```C : UsersVinay> python34python -m venv "Tempaaa bbb"

C : UsersVinay> "Tempaaa bbbScriptspip"--version
C : Tempaaa bbblibsite-packages (python 3.4)의 pip 6.0.8

C : UsersVinay> pyzzer -i "Tempaaa bbbScriptspip.exe"
발사기가 있습니다.
Shebang : #! "C : Tempaaa bbbScriptspython.exe"

아카이브 내용 :
__main__.py

C : UsersVinay> "Tempaaa bbbScriptspython"-m pip install -U pip
pip 버전 6.0.8을 사용하고 있지만 버전 9.0.1을 사용할 수 있습니다.
'pip install --upgrade pip'명령을 통한 업그레이드를 고려해야합니다.
https://pypi.python.org/ 에서 pip 수집 [...] / pip-9.0.1-py2.py3-none-any.whl # md5 = 297 [...]
캐시 된 pip-9.0.1-py2.py3-none-any.whl 사용
수집 된 패키지 설치 : pip
기존 설치 발견 : pip 6.0.8
pip-6.0.8 제거 :
pip-6.0.8을 성공적으로 제거했습니다.

pip-9.0.1을 성공적으로 설치했습니다.

C : UsersVinay> "Tempaaa bbbScriptspip"--version
C : Tempaaa bbblibsite-packages (python 3.4)의 pip 9.0.1
```

Windows의 virtualenv 스크립트는 distlib가 PC / launcher.c에서 자체 shebang 프로토콜을 정의하므로 작동합니다. 아마도 POSIX는 신뢰할 수없는 커널 대신 사용자 공간 shebang 파서와 비슷한 것을 가질 수 있습니다.

신뢰할 수없는 커널 대신 사용자 공간 shebang 파서

왜 Bash가 이것을 할 수 없는지 모르겠습니다. (예를 들어) 커널 공간이라고 생각하지 않습니다.

Shebang은 쉘 외부에서 사용할 수 있어야하기 때문에 커널 공간에서 처리됩니다.

기술적 세부 사항:
UNIX 계열 시스템 (Linux, Mac, * BSD, ...)에서는 fork () 및 exec ()를 통해 새 프로그램이 생성됩니다. exec ()는 새 프로그램을 실행하는 Windows의 CreateProcess ()와 유사합니다. UNIX 계열 시스템에서 exec ()는 결국 시스템 호출 execve ()를 호출합니다. 후자의 기능은 커널에서 구현되므로 shebang 구문 분석은 커널에서 수행됩니다.
C 라이브러리에서 구현할 수 없거나 정적 연결된 프로그램이나 시스템 호출을 직접 사용하는 프로그램 (int 80 또는 sysenter 등을 통해)은 작동하지 않습니다.

경로에 공백이있는 가상 환경의 생성을 금지해야 할 수도 있습니다. 어쨌든 예상대로 작동하지 않습니다

Shebang은 쉘 외부에서 사용할 수 있어야하기 때문에 커널 공간에서 처리됩니다.

예,하지만 시스템 호출이 ENOEXEC 반환하면 쉘이 자체적으로 구문 분석을 수행 할 수 없습니까? 나는 그것이 벌레의 캔일 수 있다는 것을 알고 있습니다 ...

흥미로운 정보-Linux의 커널 기능은 오랜 Python 커미터 Martin von Löwis가 작성한 것으로 보입니다. :-)

이 페이지는 또한 흥미로운 읽기였습니다 : http://www.in-ulm.de/~mascheck/various/shebang/

예,하지만 시스템 호출이 ENOEXEC 반환하면 쉘이 자체적으로 구문 분석을 수행 할 수 없습니까?

쉘과 기본 커널 사이의 IMO 다른 의미는 사용자와 개발자에게 많은 혼란을 가져올 것입니다. 현재 최소한 bash 및 zsh는 execve ()가 실패 할 때 구문 분석을 수행하지만 더 나은 오류보고를 위해서만 폴백을 제공하지 않습니다.

흥미로운 정보-Linux의 커널 기능은 오랜 Python 커미터 Martin von Löwis가 작성한 것으로 보입니다. :-)

흥미 롭군요! 나는 그것을 눈치 채지 못했습니다 :) 또한 추가 자료에 감사드립니다. 커널 소스 코드를 읽는 것이 가장 빠른 방법이지만 이러한 문서는 여전히 도움이됩니다.

@fbidu 의 아이디어에 대해 :

경로에 공백이있는 가상 환경의 생성을 금지해야 할 수도 있습니다. 어쨌든 예상대로 작동하지 않습니다

취약한 경로가있는 가상 환경을 만드는 것은 경로 처리의 코너 케이스를 테스트하는 데 유용합니다. 이 예에서는 커널이 어떻게 손상되는지 보여줍니다. 내 생각은 내가 http://bugs.python.org/issue28446에 게시 한 패치처럼 금지하는 대신 경고를 추가하는 것입니다.

# 994 "Pip이 virtualenv 경로의 공간으로 실패"하는 것이이 문제의 중복이라고 생각합니다.

https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253의 "virtualenv가 깨지기 쉬운 커널 shebang 구문 분석으로 손상되었습니다."의 주석을 반복하고 싶습니다. 그런 정신에서 # 1014 "경로에 이모티콘이있는 디렉토리와 호환되지 않음"은 취약한 커널 shebang 구문 분석으로 인해 virtualenv가 손상되는 또 다른 예입니다. 사실 경로에 ASCII가 아닌 문자가 있으면 문제가 발생합니다.

깨지기 쉬운 커널 shebang 구문 분석의 세 가지 측면을 모두 하나의 문제로 수집하여 하나의 수정이 virtualenv 경로에서 공백, 길이 및 비 ASCII 문자를 처리 할 수 ​​있는지 확신 할 수 있습니까? 가장 오래된 문제이기 때문에이 문제를 추천합니다.

수정 작업을하는 동안 a) 공백이 있거나 b) 너무 길거나 c) 비 ASCII 문자가있는 경로에 환경을 생성하라는 요청을 받았을 때 virtualenv가 경고를 출력하는 것이 좋을 것 같습니다. 일부 문서의 문장도 도움이 될 것입니다.

사실 경로에 ASCII가 아닌 문자가 있으면 문제가 발생합니다.

# 1014의 이유는 커널이 아닌 virtualenv에 있다고 생각합니다. # 900에서 매우 유사한 문제를 수정하는 패치가 있습니다.

안녕하세요,
이것은 매우 성 가시고 겉보기에 너무나 단순한 것 (적어도 단순한 원인)으로 인해 엄청난 시간 낭비입니다.

이름을 바꾸거나 (가능한 경우) 링크를 사용하는 것은 어떻습니까 (공백없이 /virtualenvs/python3.5와 같은 디렉토리를 만든 다음 원래 디렉토리에 대한 소프트 링크가되게할까요?).

공간없이 /virtualenvs/python3.5와 같은 디렉토리 생성

다른 프로젝트 virtualenvwrapper는 매우 유사한 작업을 수행했습니다.

겉보기에는 너무 단순 해 보입니다 (적어도 단순한 원인).

둘 다 간단하지 않습니다. 원인은 커널 구문 분석 코드와 관련이 있으며 해결 방법에는 사용자 공간 처리가 필요합니다.

6 년 후에도 여전히 문제입니까?

이 문제는 2 주 전에 나를 괴롭 혔습니다. 예, 여전히 문제입니다.

virtualenv 문제가 아니라 Unix 문제이므로 Unix 커널 제한이 제거되지 않는 한 "수정"되지 않을 가능성이 있습니다.

첫 번째 virtualenv 버그는 virtualenv가 일상적으로 virtualenv 사용자에게 문제를 일으키는 제한 사항이 있음에도 불구하고 특정 Unix 커널 기능을 사용하여 쉘 실행 파일을 구현하기로 결정했다는 것입니다. Virtualenv는 쉘 실행 파일에 대해 다른 메커니즘을 사용하여이 문제를 해결할 수 있습니다. 두 번째 virtualenv 버그는 첫 번째 버그를 해결하기 위해 사용자가 어떻게 virtualenv를 사용해야하는지에 대한 문서가없는 것입니다 (ASCII 전용 문자가 있고 공백이없는 짧은 경로에서만 virtualenv를 작성하십시오). 세 번째 virtualenv 버그는 사용자가 첫 번째 버그를 트리거하는 virtualenv 경로를 선택하고 유용한 경고 메시지를 출력하는 경우를 감지하는 메커니즘이 없다는 것입니다. virtualenv 기여자가 상황을 개선하기 위해 할 수있는 일이 많이 있습니다.

@JDLH 첫 번째 "버그"에 대해 : virtualenv가 아니라 distlib에 의해 처리되지 않고 https://bitbucket.org/pypa/distlib/pull-requests/31/에 구현이

첫 번째 virtualenv 버그는 virtualenv가 특정 Unix 커널 기능을 사용하여 쉘 실행 파일을 구현하기로 선택했다는 것입니다.

@JDLH 이것은 virtualenv 에만 국한되지 않습니다.- _all_ Unix 스크립트 파일 (즉, shebang 줄이있는 파일)은이 커널 기능을 사용합니다.-그리고 virtualenv (또는 그 밖의 다른 것)이 재발 명 할만한 설득력있는 이유가 없습니다. 기존 메커니즘이 널리 사용되고 잘 이해 될 때 완전히 새로운 스크립트 디스패치 방법입니다. 인터프리터 경로 ( virtualenv 관련 없음)에 공백이있는 스크립트를 직접 작성하면 동일한 문제가 발생합니다.

virtualenv 기여자가 상황을 개선하기 위해 할 수있는 일이 많이 있습니다.

기여자의 시간에 대한 요청이 많을 것입니다. 이 문제는 공백이있는 긴 경로 / 경로가 사용되는 비교적 적은 수의 경우에 영향을줍니다. 영향을받는 사용자 중 일부가 탐지 및 경고 메시지에 도움이되는 패치를 제안함으로써 기여자들을 도울 수있을 것입니까? 그냥 아이디어.

@ yan12125 distlib 사용하면 원하는대로 shebang 줄에서 실행 파일을 지정할 수 있습니다. 공백 / 긴 줄에 대한 커널 제한은 이전 버전과의 호환성으로 인해 Linux 개발자가 수정하지 못할 수 있습니다. shebang 실행 파일 (Mozilla 스크립트 해킹에 해당하는 일반화)에 대한 사용자 지정 문자열을 제공 할 수 있으며 distlib 는 스크립트에 작성해야하므로 distlib 처럼 실험 할 수 있습니다

이것은 virtualenv에만 국한되지 않습니다.

@vsajip 이것은 진정한 진술입니다. 다른 소프트웨어는 virtualenv가 선택한 동일한 shebang 메커니즘을 사용하지만이 문제의 요점을

virtualenv (또는 기타)가 완전히 새로운 스크립트 디스패치 방법을 재창조 할 설득력있는 이유가 없습니다.

당신이 말하는 것은 수년에 걸쳐이 문제를 겪은 사람들이 경험 한 문제가 "강력한"것이 아니라는 것입니다. 나는 많은 사람들이 수년에 걸쳐이 문제를 발견하고 논평하는 이유는 그들이 문제를 "매력적"이라고 생각하기 때문이라고 생각합니다. 확실히 그렇습니다.

영향을받는 사용자 중 일부가 탐지 및 경고 메시지에 도움이되는 패치를 제안함으로써 기여자들을 도울 수있을 것입니까? 그냥 아이디어.

저는 virtualenv에서 대부분의 작업을 수행하는 충실한 사람들과이 문제가 그 영향을 줄이기 위해 노력할만큼 충분히 매력적이라고 ​​생각하는 방문자를 모두 포함하기 위해 "기여자"라는 단어를 선택했습니다. 문제가 매력적이라고 ​​생각하는 우리는 패치를 제공해야한다고 말하는 것이 타당합니다.

virtualenv를 잘 아는 충실한 사람들이 유망한 접근 방식을 제안 할 수 있다면 도움이 될 것입니다. virtualenv ~/my\ long\ path\ with\ spaces 를 입력하는 사용자에게 경고 메시지를 삽입하려면 해당 코드가 가장 적합한 위치는 어디입니까? 첫 번째 기여를하는 방문자의 장애물을 제거하기 위해 충실한 사람들이 공유 할 수있는 그러한 패치에 대한 명백하지 않은 제약이 있습니까? 충실한 사람들은 그러한 패치를 받아들이는 것에 대해 역사적인 반대를 가지고 있습니까? (내 말은, 경고 메시지를 추가 할 생각을 처음으로 생각한 사람이 될 수는 없습니다. 아직 발생하지 않은 이유가있을 것입니다.)

공백을 포함하고 수정할 수없는 잘 알려진 경로가 있습니다. /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs . 따라서 iCloud에서 virtualenv 로 관리되는 일부 스크립트를 유지하려는 사람은 누구나이 문제에 부딪 힙니다.

virtualenv를 잘 아는 충실한 사람들이 유망한 접근 방식을 제안 할 수 있다면 도움이 될 것입니다.

글쎄, 우리가 알고 있다면, 우리가 그렇게 한 것에 대한 비판의 양을 감안할 때 우리는 아마도이 문제를 너무 오랫동안 해결되지 않은 채로 두지 않았을 것입니다 :-(

virtualenv ~ / my long path를 공백으로 입력하는 사용자에게 경고 메시지를 삽입하려면 해당 코드가 가장 좋은 위치는 어디입니까?

인수 구문 분석 코드를 살펴보고 경로가 결정되면 검사를 추가하여 시작할 수 있습니다.

첫 번째 기여를하는 방문자의 장애물을 제거하기 위해 충실한 사람들이 공유 할 수있는 그러한 패치에 대한 명백하지 않은 제약이 있습니까?

여기에서 문제 목록을 검색하여이 문제 및 기타 문제에 대한 다양한 의견을 수년간 검색하여 찾을 수 있지만 먼저 경로가 작동 할 때 경로를 거부 할 필요가 없습니다. 즉, OS의 제한 사항을 파악해야합니다. 부과합니다. 이는 시스템마다 크게 다릅니다. Windows는 공백과 긴 파일 이름을 허용하고, 일부 Unix 시스템은 공백을 허용하고, 일부는 인용 할 공백이있는 경로가 필요하고, 일부는 매우 짧은 길이 제한 (32 자?), 일부는 더 길다. ... 많은 제한 사항이 잘 문서화되어 있지 않으며 매우 적습니다. 기여자는 사용 가능한 문서를 보완하기에 충분한 모든 가능성을 테스트 할 수있는 충분한 시스템에 액세스 할 수 있습니다.

충실한 사람들은 그러한 패치를 받아들이는 것에 대해 역사적인 반대를 가지고 있습니까?

아니요, "첫눈에 생각하는 것만 큼 간단하다고 가정하지 말고 우리가 지원해야하는 다양한 (때로는 꽤 모호한) 시스템을 모두 무시하지 마십시오".

누군가가 이것을 찌르고 싶어하고-내가 개인적으로 "첫 번째 기여"로 추천하는 것이 아니라는 것을 알고 있어야한다면, 그들은 다양한 이슈에서 사용 가능한 모든 역사를 읽는 것으로 시작해야합니다 (일부 이것과 연결되어 있고, 다른 것들은 아마도 그렇지 않을 것입니다. 일부는 아마도 pip 트래커와 어쩌면 distlib 또는 setuptools 트래커에있을 것입니다.) 그리고 다양한 OS에 의해 부과 된 제약을 새로운 PR에 요약합니다. "이러한 조건이 충족되지 않으면 virtualenv에서 사용하는 shebang 헤더가 예상대로 작동하지 않으므로 virtualenv는 명시된 조건과 일치하지 않는 디렉토리에서 환경 생성을 지원하지 않습니다"라는 문서 패치로 제안하십시오. PR에는 문서화 된 조건이 충족되지 않을 경우 경고하는 코드 변경이 포함되거나 향후 작업으로이를 제안 할 수 있습니다 (내가 기억하는 바와 같이 시스템 세부 정보를 정확히 조사하여 제한이 적용되는 것을 알 수 있습니다. "Ubuntu 패치 된 커널로 "...). 개인적으로 나는 일이 실패 할 것으로 알려진 경우에만 플래그를 지정하고 확실하지 않은 경우 침묵한다는 경고로 괜찮을 것입니다. 하지만이 단계에서는 문서 전용 패치로도 괜찮습니다.

그런 다음 다루는 시스템에 액세스 할 수있는 사람들로부터 패치에 대한 검토를 받아야합니다. 앞서 언급했듯이 핵심 개발자는 FreeBSD, OpenBSD 또는 Solaris를 사용하지 않기 때문에 여기서 실제로 도움을 줄 수 없습니다. 또는 ...

부분 작업을 수행하고 문서와 OSX에 대한 경고 만 추가 한 PR을 만들 수도 있습니다. 이것이이 문제에 대한 불만을 멈출 수 있을지는 모르겠지만 (가장 자주 발생하는 시스템이 무엇인지 모르겠습니다) 충분할 수도 있습니다. 아마도 OSX를 사용하는 핵심 개발자 중 한 명이이를 병합해도 괜찮을 것입니다.

도움이 되나요?

이해가 안되는 부분이 있지만 (예 : bin/pip

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

그런 다음 현재 pip 스크립트를 real-pip ? 왜 우리가 shebang을 직접 사용 해야하는지 모르겠습니다.

@ raxod502 나는 이것이 Windows에서 작동하지 않을 것이라는 것을 알고 있다고 가정합니다. 또한 두 번째 줄에 필요한 "정상적인"주문이 당신이주는 것보다 더 복잡하다고 생각합니다 (개인적으로 이유는 모르겠지만). 웹 검색을 통해 적절한 접근 방식을 찾을 수 있습니다. 접근 방식으로 " 또는 $ 문자가있는 경로에 대해 어떤 일이 발생합니까?

이러한 종류의 문제를 해결할 수 있다고 가정하면 다음 단계는 PR (위의 의견에 따라)을 제출하는 것이며 이에 대한 세부 사항에 대해 토론 할 수 있습니다. 관련된 Unix에서 작업하는 virtualenv 코어 커미터 중 하나 이상을 확보해야합니다. Windows 사용자로서 저는 이와 같은 Unix 관련 PR을 병합하지 않을 것입니다.

뿡뿡
@ raxod502 가 제안한 솔루션은 .bat 스크립트 파일 afaik?

@gst 짧은 대답, 아니요. 긴 대답은 http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html입니다 . 수년 동안이 점에 대해 많은 토론이 있었고 누군가가 다른 솔루션을 제안 할 때마다 exe 래퍼, 문제가 있습니다.

이 경우이 문제는 Windows에는 존재하지 않습니다 . 따라서 Windows 환경에서 아무것도 변경할 이유가 전혀 없습니다. 모든 변경 은 Unix로만 제한

좋은 대답을 위해 thx :)

exe 래퍼 외에는 문제가있었습니다.

개인적으로 나는 그것과 함께 살 수 있습니다 (필요하다면).

긴 경로와 공백이있는 경로를 처리하기 위해 distlib 을 업데이트했습니다. Harald Nordgren의 패치를 직접 사용하지는 않았지만 (몇 가지 문제가있었습니다-예를 들어 테스트가 없었 음) 접근 방식은 동일합니다-실행 파일로 '/ bin / sh'를 사용합니다. pip / virtualenv 관리자는 현재 버전의 distlib 저장소를 로컬로 벤더 링 한 후 테스트 할 수 있습니다.

pip의 개발 버전은 이제 distlib의 최신 버전을 공급합니다. 즉, pip는 이제 디렉터리 이름의 공백을 잘 처리합니다.

내가 이해하는 바와 같이, pip의 다음 릴리스와 virtualenv 릴리스가 만들어지면이 문제가 해결 될 것입니다. 생성 된 모든 새로운 virtualenv는 pip에 의해 설치된 바이너리와 마찬가지로 경로의 공간을 지원합니다 (setuptools와 같은 일부 기발한 경우 제외). 'pip에 의해 직접 설치되지 않은 래퍼).

저는 gvfs를 사용하여 사용자 공간에 삼바 공유를 마운트하고 gvfs에 의해 생성 된 마운트 경로의 펑크로 인해 virtualenv / pip 등을 찾기 시작했습니다.

경로에는 공간이 없지만 virtualenv / pip 등을 무릎에 가져가는 다른 많은 것들이

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

내가 볼 수있는 한 현재 gvfs에는 생성 된 마운트 지점의 경로에서 구두점을 방지하는 옵션이 없습니다. 내 유일한 해결 방법은 gvfs 마운트에 virtualenv를 생성하지 않는 것입니다.

@pradyunsg 다음 pip 릴리스에 대한 일정이 있습니까? 마지막 것은 1 년이 넘었고 ,이 정말 간단한 수정이 virtualenv에 나타날 때까지 너무 오래 기다리는 것은 어리석은 것 같습니다.

안녕하세요 @ raxod502!

네, 곧 꺼내고 싶습니다. 문제는 PEP 518을 출시 할 개발자 시간이 부족하다는 것입니다. PEP 518이없는 핍 10이있을 수도 있지만, 계획을 정할 시간을 찾는 데 달려 있습니다.

이 버그는 2018-04-14에 출시 된 pip 10.0.0에 의해 수정 된 것으로 보입니다. 엄밀히 수정을 말하는 것은이었다 distlib 0.2.6 자신과 PIP에 vendored하고, PR4819 첫 번째 주사위 10.0.0b2 등장 년 10 월 2017 년.

기본 수정 사항은 distlib의 커밋 9285cca에있는 것으로 보입니다 . vsajip이 2017 년 5 월 28 일에 여기에서 언급 했듯이 접근 방식은 Harald Nordgren의 아이디어를 따릅니다. 간단한 경우 (OS가 Posix가 아니거나 경로가 충분히 짧고 공백이 없음)에는 계속 단순 shebang을 사용하지만 단순하지 않은 경우에는 사용합니다. 대신 /bin/sh exec 명령을 사용하여 길거나 공백이 포함 된 경로를 처리 할 수 ​​있습니다.

Mac OS X 10.11.6에서 빠른 테스트를 수행하여 공백이있는 긴 경로에 가상 환경을 만든 다음 pip3 install 를 호출하면 작동하는 것 같습니다. 이 버그에 설명 된 모든 것이 모든 OS에서 수정되었는지 완전히 테스트하지는 않았습니다.

Ubuntu 16.04.5 LTS를 사용하여 pip를 9.0.1에서 18.1로 업그레이드하고 (달력 기반 버전으로 전환) virtualenv를 15.0.1에서 16.0.0으로 업그레이드 한 후 문제가 사라진 것 같습니다.

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

이제 모든 pip 명령은 루트 경로에 공백이있는 virtualenv에서 제대로 작동합니다.

@JLDH 및 @gandie 에서 확인 한대로이 문제는 이제 해결되었습니다. 최신 버전의 pip 및 virtualenv는 virtualenv의 루트에 공백이있을 때 제대로 작동합니다.

이거 닫아! 기본 수정 @vsajip에 대한 작업에 감사드립니다!

이전 티켓 :하지만 안되는 이유

! / usr / bin / env 파이썬?

@rirl , 닫힌 이슈에 댓글을 남기는 것은 아이디어의 관심을 끌 가능성이 낮습니다. 문제에 해결책이 주어졌습니다. 이 솔루션을 사용하는 새로운 virtulenv가 다른 작업을 수행함으로써 개선 될 것이라고 생각한다면 새로운 변경을 제안하는 것입니다. 새로운 이슈를 여는 것을 고려하고, 어떤 변화가 일어나야한다고 생각하는지 말하고, 왜 변화가 새로운 virtualenv보다 나은지에 대한 사례를 만드십시오.