Virtualenv: pip 실행 파일에서 Shebang 길이가 초과되었습니다.

저도 이 문제를 겪고 있습니다.

나도.

해결 방법에 감사드립니다!

래퍼 스크립트는 실제로 setuptools(sdist에서 설치하는 경우) 또는 distlib(휠에서 설치하는 경우)에 의해 생성됩니다. 따라서 이 문제에 대한 수정 사항은 해당 프로젝트에서 실제로 요청해야 합니다.

그러나 그것이 OS 제한이라면 실행 가능한 수정이 _없을까요_? 한때 Perl이 스크립트를 실행하기 위해 마법의 주문을 사용했다는 것을 기억하는 것 같습니다.

#!/bin/sh
eval 'exec /the/long/interpreter/path/to/python $0 ${1+"$@"}'

Python이 eval-exec 행을 실행하지 않도록 추가 항목이 필요하지만 작동할 수 있습니다.

setuptools 및 distlib에 대한 기능 요청으로 이와 같은 것을 제안하고 싶은 사람이 있다면 좋을 것입니다.

따라서 python virtualenv가 생성되는 경로가 너무 길어지면 해당 virtualenv의 pip를 사용하면 작동하지 않습니다.

이 문제가 발생하는 시스템에서 virtualenv 를 실행하는 경우 _정말_ 좋을 것입니다. 명령은 이러한 긴 경로 이름을 가진 디렉토리에 있는 것이 본질적으로 지원되지 않는다는 일부 경고(또는 오류)를 출력합니다. 현재 기본값.

이것도 때려요. pwd에 대한 _매우_ 긴 경로가 있는 Jenkins 빌드 내에서 pip 를 실행하고 있기 때문에 특히 문제입니다. 흥미롭게도 동일한 빌드 슬레이브가 여러 개 있으며(모두 BINPRM_BUF_SIZE가 128로 설정되고 동일한 pip 및 python 및 virtualenv 버전이 있음) 경로 길이가 다양하더라도 일부에서는 이러한 현상이 발생하지만 다른 경우에는 발생하지 않습니다.

@b-long의 제안이 마음에 듭니다. virtualenv 가 현재 시스템에서 작동하지 않는 래퍼를 만들려는 경우 최소한 사용자에게 경고를 제공해야 합니다.

virtualenv가 이 상황을 감지할 수 있는 방법이 명확하지 않습니다. 우리는 C 헤더의 값을 정확히 사용할 수 없으며 이 제한이 있는 시스템에 있음을 어떻게 감지할지 모르겠습니다(Windows에는 없지만 OSX에는 있습니까?)

virtualenv 문제가 아니라 OS 제한으로 이 문제를 닫고 싶습니다.

가치있는 일에 대한 몇 가지 생각...

1. ctypes 할 수 있습니까?
2. 다음과 같이 간단한 것은 어떻습니까?

# on Linux, BINPRM_BUF_SIZE == 128, giving us a maximum shebang length of 127
# 2 bytes for #!, 11 bytes for '/bin/python' leaves us with 114
if sys.platform() == 'Linux' and len(home_dir) > 114:
    log.warn("bin/activate may not work your system, as the length of the shebang line will exceed 128 characters")

1. 죄송합니다.
2. 나는 Windows 사용자이므로 의견이 없습니다. 이것이 합리적이라고 생각한다면 PR을 올리고 Linux 사람들이 생각하는 것을 보는 것이 좋습니다 ...

다른 사용자들도 내가 제안한 변경 사항을 높이 평가할 것이라고 확신합니다. 의견을 제시하고 PR에 영감을 주기 위해 이것을 열어둘 수 있습니까? @jantman 과 @pfmoore 감사합니다 :smile:

BINPRM_BUF_SIZE 는 커널 헤더에 정의되어 있으며 소수의 커널 기능에서만 사용되는 것 같습니다. 프로그래밍 방식으로 이를 감지할 수 있는 방법이 없다고 생각합니다(헤더에서 읽기가 짧고 실현 가능하지 않음).

즉, 이것이 곧 변경되지 않을 것이라고 가정하는 것이 합리적이라고 생각합니다( 여기에 최대 shebang 길이에 대한 간략한 개요가 execve(2) 매뉴얼 페이지 의 "참고" 섹션에도 명확하게 나와 있습니다. 여기에서 "실행 가능한 쉘 스크립트의 첫 번째 줄에는 최대 줄 길이가 127자까지 허용됩니다."라고 명시되어 있습니다.

모든 POSIX 호환 운영 체제에는 일종의 제한이 있다고 가정하지만, 그 중 일부, 특히 BSD 변형에는 8,000자를 초과하는 제한이 있을 수 있습니다.

위의 제안(플랫폼이 Linux이고 줄이 127자보다 긴 경우)처럼 순진한 것을 단순히 하드 코딩하는 것이 합리적인 솔루션인 것처럼 보이지만, 나에게는 지나치게 조잡하고 구체적이며 융통성이 없습니다.

virtualenv 에 너무 많은 오버헤드를 추가하지 않는 방식으로 이것을 프로그래밍 방식으로 테스트하는 방법에 대해 여전히 생각하고 있습니다. d 약간의 오버헤드가 허용될 수 있다고 가정).

주어진 경로가 허용 가능한 길이인지 여부를 테스트하는 간단한 개념 증명 코드가 있지만 디스크에 파일을 작성한 다음 출력을 캡처하기 위해 파일을 실행하기 때문에 다소 보기 흉합니다. 예제 및 출력은 다음과 같습니다. https://gist.github.com/jantman/ba39f98936643bc948bd

밤이라고 불러야 하겠지만, 이쯤에서 다시 해봐야겠습니다. 다른 Linux 사용자나 비슷한 제한이 있는지 여부를 확인할 수 있는 다른 OS 사용자의 의견에 감사드립니다.

한계에 대해 가정하는 것과 같은 까다로운 작업을 수행하는 대신 기능 테스트 bash 스크립트를 만드는 것이 어떻습니까? 파이썬이 올바르게 호출되면 모든 것이 복숭아 같고 그렇지 않으면 그렇지 않습니다.

다시 말해서:

1. 이 문제를 해결하려면 setuptools 및 distlib PR을 제출하세요. 코드는 virtualenv 또는 pip에 없습니다.
2. 허용되려면 코드가 Linux뿐만 아니라 OSX, BSD 등 지원되는 모든 플랫폼에서 작동해야 합니다(물론 다른 방법이 없는 경우 플랫폼별 조건부 허용).

virtualenv 문제가 아니므로 이 문제를 닫습니다(긴 디렉토리 이름에 전체 Python 인터프리터를 설치하여 동일한 효과를 얻을 수 있음).

우리는 방금 이 문제를 해결했습니다.

PATH에서 파이썬을 사용하지 않는 이유는 무엇입니까? virtualenv는 이미 bin dir 앞에 추가합니다.

#!/usr/bin/env python

virtualenv는 이미 bin dir 앞에 추가합니다.

virtualenv를 활성화하는 경우에만. Virtualenv는 활성화 없이 사용하는 것을 지원합니다.

누군가가 이것을 혼란스럽게 생각한다면:

이 문제에 대한 해결 방법은 pip를 직접 실행하지 않고 virtualenv의 python 인터프리터를 실행하고 pip 스크립트를 실행할 소스로 python에 전달하는 것입니다.

즉, pip install -r requirements.txt 대신 python -m pip install -r requirements.txt