Virtualenv: virtualenv의 스크립트에 표준 라이브러리 스크립트 포함

pyenv rehash를 수행한 후에도 여전히 발생합니까?

pyenv rehash 전후에 shim을 실행할 때 무엇을 실행합니까?

나는 이것이 pyenv와 관련이 있다는 느낌이 듭니다.

pyenv rehash를 수행한 후에도 여전히 발생합니까?

네.

pyenv rehash 전후에 shim을 실행할 때 무엇을 실행합니까?

$#$ 2to3 가 포함된 apt 패키지가 설치되지 않은 system Python이 선택되었으므로 다음과 같이 표시됩니다.

pyenv: 2to3: command not found

The `2to3' command exists in these Python versions:
<list>

두 경우 모두.

나는 이것이 pyenv와 관련이 있다는 느낌이 듭니다.

pyenv 는 관련이 없습니다. 예상되는 동작은 두 번째 which 가 python 처럼 virtualenv 의 심을 반환하는 것입니다. 버그는 virtualenv 가 생성하지 않는다는 것입니다. (나는 이것이 뻔하다고 생각했다. 아마 아닐 것이다.)

아, 알겠습니다... 활성화 후 PATH 는 무엇인가요?

(나는 지금 이것을 재현하려고 할 수 있는 기계에 있지 않다)

(test) vmuser<strong i="5">@ubuntuvm</strong>:~$ echo $PATH
/home/vmuser/test/bin:/home/vmuser/.rbenv/shims:/home/vmuser/.rbenv/bin:/home/vmuser/.pyenv/shims:/home/vmuser/.pyenv/bin:/home/vmuser/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/home/vmuser/.rvm/bin
(test) vmuser<strong i="6">@ubuntuvm</strong>:~$ ls /home/vmuser/test/bin
activate       activate_this.py  pip     python3
activate.csh   activate.xsh      pip3    python3.6
activate.fish  easy_install      pip3.6  python-config
activate.ps1   easy_install-3.6  python  wheel

이 문제를 해결하려면 virtualenv 내에서 동등한 기능과 함께 python -m lib2to3 를 사용할 수 있습니다.

/cc other @pypa/virtualenv-committers 표준 라이브러리의 스크립트를 생성할 때 virtualenv에 추가하는 것이 좋다고 생각한다면 좋은 생각입니다.

나는 양면적이다.

저는 -0.5입니다. 지금까지 문제로 표시되지 않은 추가 혼란이므로 필요가 거의 없다고 가정합니다. EOL이 임박한 Python 2가 여기서 차이를 만든다고 확신하지 못합니다. 추가 스크립트는 Windows의 비가상 환경에서도 PATH 에 있지 않으므로 존재한다는 기대가 보편적이지 않습니다.

나는 이것이 일반적인 접근 방식으로 작동해야한다고 생각합니다. 호스트 환경의 모든 응용 프로그램은 가상 환경 수준에서 사용할 수 있어야 합니다.

EOL이 임박한 Python 2가 여기서 차이를 만든다고 확신하지 못합니다.

+1

그것은 여기에서도 내 관심사가 아닙니다. :)

추가 스크립트는 Windows의 비가상 환경에서도 PATH 에 없습니다.

오. Scripts/ 디렉토리에 있지 않습니까? 내 이해는 현재 python.org 설치 프로그램이 해당 디렉토리를 PATH에 추가하므로 실행할 수 있다는 것입니다.

호스트 환경의 모든 응용 프로그램은 가상 환경 수준에서 사용할 수 있어야 합니다.

음... "응용 프로그램"은 여기에서 약간 모호합니다. 스크립트를 말하는 것입니까 아니면 다른 것을 말하는 것입니까? 무슨 말인지 명확히 해 주시겠습니까?

우리가 이렇게 하면 어쨌든 호스트 환경의 모든 스크립트를 포함하는 데에는 -1이고 표준 라이브러리에서 지원하는 스크립트를 포함하는 데에는 양가적이라는 점에 유의하십시오.

오. Scripts/ 디렉토리에 있지 않습니까?

아니요, Scripts 에 있는 모든 것은 설치된 라이브러리(기본 설치의 pip, easy_install 및 wheel)에 대한 진입점 래퍼입니다. 조금 더 살펴보면 2to3.py 가 Tools/scripts 에 있지만(60개 이상의 다른 스크립트가 상당히 혼합되어 있음) 그 디렉토리는 PATH 에 있지 않습니다. 사용자는 "PATH에 Python 추가"를 선택합니다.

우리가 이렇게 하면 어쨌든 호스트 환경의 모든 스크립트를 포함하는 데에는 -1이고 표준 라이브러리에서 지원하는 스크립트를 포함하는 데에는 양가적이라는 점에 유의하십시오.

최소한 기본 설치보다 더 많은 것을 PATH에 추가해서는 안 된다고 주장하고 싶습니다. 이것은 우리가 이것을 한다 해도 Windows에서는 하지 않는다는 것을 의미합니다.

pradyunsg는 2시간 전에 virtualenv의 bin에 표준 라이브러리 스크립트 포함/가상 환경의 스크립트에 표준 라이브러리 스크립트 포함이라는 제목을 변경했습니다.

이것은 약간의 범위 변경이라는 점에 유의하십시오. OP는 특히 2to3 에만 관심이 있었고 특히 virtualenv를 활성화해도 시스템 2to3 을 가리지 않았습니다 . 그것이 중요한지 여부에 대해서는 언급할 수 없습니다(Windows에서는 이러한 일이 발생하지 않는다고 주장했지만 Unix에서 이것이 문제라고 느끼는지 말할 수 있는 관련 경험이 없음). 그러나 다른 스크립트가 "표준 라이브러리 스크립트"인지 알지 못하면 이것이 중요한 요점인지 말할 수 없습니다.

흠, pyvenv 는 아마도 또 다른 "표준 라이브러리 스크립트"일 것입니다. 저는 virtualenv 환경에서 venv를 실행하는 버전으로 시스템 버전을 섀도잉하고 싶지 않다고 확신합니다. 실질적인 이익이 없음).

OP는 ... 관심이 ... 특히 virtualenv를 활성화해도 시스템 2to3을 가리지 않았습니다.

(이 문구가 제 입에 무엇을 담고 있는지 잘 모르겠습니다. 양방향으로 해석될 수 있습니다.)

명확성을 위해 2to3 에 대한 심을 생성하기 위해 virtualenv 를 요청합니다.

(원본 게시물을 예상 동작으로 수정하겠습니다. 생략하면 혼란을 일으키고 있습니다.)

(원본 게시물을 예상 동작으로 편집하겠습니다)

완료. 또한 사용자가 PATH 에 있을 것으로 예상한 이유를 설명했습니다.

이 말이 내 입에 무엇을 담고 있는지 모르겠다

귀하의 의견을 잘못 전달하여 죄송합니다. 설명해주셔서 감사합니다! (요청하신 내용을 제대로 이해한 것 같습니다만, 제가 잘못 다시 한 것뿐입니다...)

또한 사용자가 PATH에 있을 것으로 예상한 이유를 설명했습니다.

참조한 링크가 약간 혼란스럽습니다. 사용자는 신뢰할 수 있고 xenial에서 작동하지만 바이오닉에서는 작동하지 않는 프로세스를 가지고 있는 것 같습니다. 문제가 virtualenv에 있는 경우 그 이유가 명확하지 않습니다. (참고: 이것은 편향입니다. 그럼에도 불구하고 virtualenv가 2to3.py 를 복사 하지 않는 경우가 분명하므로 원래 문제가 더 미묘하더라도 유효해야 하는지 여부에 대한 논의).

virtualenv에 2to3용 shim을 생성하도록 요청하고 있습니다.

우리는 shim을 만들지 않을 것입니다. 우리가 할 일은 2to3.py 스크립트를 복사하는 것뿐입니다. shim이 필요한 경우(그것은 pyvenv의 문제라고 생각합니다) 우리가 그것을 처리하지 않았을 것입니다.

아니요, 스크립트에 있는 모든 것은 설치된 라이브러리(기본 설치의 pip, easy_install 및 wheel)에 대한 진입점 래퍼입니다.

오오오오오오오오오오오오오오오 괜찮아.

이것은 약간의 범위 변경이라는 점에 유의하십시오.

나는 2to3가 특별한 눈송이라고 생각하지 않습니다. 우리가 그것을 추가한다면, 나는 누군가가 나머지를 요구하기 위해 올 것으로 기대합니다. 우리는 이것을 완전히 하거나 아예 하지 말아야 합니다. 중간에 갇히는 것은 우리가 여기서 원하는 것이 아닙니다.

(나는 모바일 UI를 싫어한다)

표준 라이브러리에 의해 지원되고 표준 Linux 설치의 경우 PATH 에 있다는 점에서 "특별"합니다.
실제로 이와 같은 다른 도구는 많지 않습니다. 2to3 외에는 $# pydoc , idle 및 pyvenv 있습니다.

$ ls ~/.pyenv/versions/3.6.9/bin
2to3          easy_install-3.6  idle3.6  pip3.6  pydoc3.6  python3.6         python3.6m         python-config  virtualenv
2to3-3.6      idle              pip      pydoc   python    python3.6-config  python3.6m-config  pyvenv
easy_install  idle3             pip3     pydoc3  python3   python3.6-gdb.py  python3-config     pyvenv-3.6

(이미 리디렉션되고 있는 python-config 도 있음)

아, @native-api에 대한 설명 감사합니다! 매우 감사. 이것이 Windows가 아닌 문제에 대한 @pfmoore 의 설명과 함께 이해하는 데 도움이 됩니다. :)

나는 여전히 그것을 포함하는 것에 대해 양면적이다.

2to3 이외의 것은 pydoc, idle 및 pyvenv뿐입니다.

누가 그 목록을 선택했는지 알고 싶습니다. 구체적으로 pyvenv입니까? Ubuntu(Windows의 bash 및 python3이 설치된 도커 이미지)에는 기본적으로 2to3이 없는 것 같지만 Python 도커 이미지에는 언급한 것과 동일한 바이너리가 있습니다(설치된 패키지에서 제공되는 pip, easy_install 및 wheel). 약간 배포에 의존적인 것 같습니다 :-(적어도 관련 바이너리 목록은 일관성이 있는 것 같습니다.

BTW, 위에서 말했듯이 이 변경을 수행하더라도 pyvenv를 포함하지 않는 것이 좋습니다.

Ubuntu(Windows의 bash 및 python3이 설치된 도커 이미지)에는 기본적으로 2to3이 없는 것 같습니다.

이는 Ubuntu에서 2to3 가 별도의 패키지로 이동되기 때문입니다.

$ apt-file search 2to3 | grep -E '/2to3[^/]*$'
2to3: /usr/bin/2to3
<...>
python2.7: /usr/bin/2to3-2.7
<...>

"표준 Linux 설치"라는 말은 배포판의 간섭 없이 Python의 Linux 빌드 스크립트에 고유한 논리를 의미했습니다. 예를 들어 소스에서 설치하는 경우( pyenv 가 수행하는 작업).

나는 이것을 받아들일 수 있고 이것을 위해 노력할 것이다.

이것은 활성화 스크립트의 일부로 pydoc을 추가하는 현재 해킹을 대체합니다.