Virtualenv: -재배치 가능한 대안

재배치 가능 플래그는 항상 실험적이며 실제로 작동하지 않았습니다. 더 이상 지원하지 않으며 기능이 완전히 삭제되었습니다 (따라서 주요 릴리스). 사용 사례를 설명하면 다른 접근 방식을 제안 할 수 있습니다.

CMD export branch && cd /build_dir && \
 apt-get update -y && apt-get upgrade -y && \
 pip3 install virtualenv && \
 virtualenv --always-copy --python=python3 env && \
 git clone http://user:pass@gitlab/dev/repo.git && \
 cd /build_dir/veil-repo/code/veil-common && \
 git checkout $branch && \
 python3 install.py -p /build_dir/veil-repo/code/cli-app/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/controller/ -v /build_dir/env && \
 python3 install.py -p /build_dir/veil-repo/code/node/ -v /build_dir/env && \
 cd /build_dir/ && \
 ./env/bin/pip3 install -r requirements.txt && \
 virtualenv --relocatable env

이것은 Dockerfile에서 발췌 한 것입니다. --relocatable 플래그를 제거하면 코드가 올바르게 작동합니까? 즉, 어떤 식 으로든 복사 할 수있는 나만의 격리 된 환경을 만들어야합니다.

도커 내부에서는 90 %라고 말할 수 있습니다. 그러나 해당 도커 코드를 유지 관리하는 사람과 연락해야하는지 확인하려면 재배치 가능을 처리하는 방법의 미묘한 차이가있을 수 있습니다.

CI 시스템이 긴 이름을 가진 디렉토리에 virtualenv를 생성하기 때문에이 기능을 가끔 사용했습니다. 이름은 #! 이 너무 길어 환경에서 스크립트를 실행할 수 없을 정도로 길어집니다.

@ Nitori- 이러한 경우 일반적으로 도구를 호출하는 python -m 형식을 사용하는 것이 좋습니다 🤔

공정 해. 많은 Python 패키지가 제대로 작동하지 않고 자체적으로 호출되는 것을 허용하지 않지만.

@ Nitori-이 경우에도 바이너리 폴더 내의 파이썬 인터프리터를 통해 실행 파일을 호출하여 항상 강제로 호출 할 수 있습니다. 예

{venv}/bin/python {venv}/bin/bad-bad-tool

{venv} 는 임의로 길 수 있습니다 👍

우리 회사에서는 파이프 라인에서 --relocatable 플래그를 사용하여 virtualenv를 재사용하고 시간을 절약합니다. GitLab을 사용하고, 초기 단계에서 virtualenv를 빌드하고, 아티팩트로 저장 한 다음 재사용하여 병렬 테스트의 무리.

우리는 virtualenv 버전을 고정하려고했지만 버그로 인해 최신 버전을 가져 와서 오늘 아침 파이프 라인이 중단되었습니다. 버그를 수정하여 고정되고 모든 것이 지금 실행되고 있으며 플래그가 제거되는 방법을 찾을 수 있습니다. 그러나 문제가 종결 되었음에도 불구하고 내 경험을 전달하기 위해 여기에서 주목할 것이라고 생각했으며 앞으로 깃발이 지원 될 것으로 기대하지 않습니다.

새로운 앱 데이터 시더에서 virtualenv를 생성하는 데 100ms 미만이 걸리므로이 접근 방식이 사용 사례에서 선호됩니다.

rpm에서 venv를 번들링하기 위해 --relocatable 를 사용합니다. virtualenv는 $ DESTDIR에서 생성되고 마지막으로 /opt/company 에서 이동됩니다.

제 경우입니다.

그러면 생성 된 경로에 대한 최종 목표를 미리 전달할 수있는 것이 도움이 될까요?

@gaborbernat 예!

@gaborbernat 그래도 virtualenv는 최종 위치에 배포하기 전에 빌드 단계에서 사용할 수 있어야합니다.

여기에서 좋은 해결책이 무엇인지 잘 모르겠습니다 🤔 저는 제안에 열려 있습니다.

이러한 경우 @gaborbernat 에서 표준 동작은 builddir과 prefix를 구분하는 것입니다.

virtualenv에는이 경우 오해의 소지가있는 DEST_DIR 인수가 있습니다. DEST_DIR 는 실제 Venv 위치로, 사실상 접두사입니다 (/ usr, / usr / local 등). 따라서 virtualenv LOCATION 문서화하면이 사실이 더 명확해질 것입니다.

그런 다음 --destdir 또는 --root 옵션을 추가 할 수 있으며 기본값은 / 입니다. 이런 식으로 virtualenv는 destdir 에서 분리되어 작동 할 수 있습니다 (다소 chroot와 유사). python, pip 및 기타 스크립트가이 문제에 어떻게 대처해야하는지 모르겠습니다.

AFAIK 문제는 생성 된 모든 콘솔 스크립트가 shebang 생성 중에 경로를 하드 코딩한다는 것입니다. shebang이 포함 된 생성 된 콘솔 스크립트를 빌드하는 동안과 배포 후 실행하는 동안 모두 작동하도록 만드는 표준 방법은 없습니다. 그것은 빌드 후 누군가가 shebangs를 고치지 않는 한입니다. 그러나 그것은 이제 가상 환경 생성의 범위를 벗어 났으므로 우리가 통제 할 수 없습니다.

@gaborbernat 당신은 우리가 이것을 setuptools에서 구현해야 함을 의미합니까? 빌드 시간과 런타임에 대상 위치에서 분리하여 사용할 수있는 shebang은 무엇입니까?

기존 virtualenv에서 shebangs를 편집하여 새 위치에서 사용할 수 있도록하는 virtualenv-relocate 스크립트를 작성하려고합니다. 다음과 같은 것 :

$ virtualenv-relocate /build/dir/venv /opt/company/app/venv
Rewriting shebang of bin/pip.
Rewriting shebang of bin/pip3.5.
...
$

나는 setuptools가 이것에도 좋은 곳이라고 생각하지 않습니다. 위치 A에 빌드 한 다음 위치 B에 배포하는 빌드 시스템의 일부 여야하는 기능입니다.

음, C 프로젝트는 단순히 PATH와 LD_LIBRARY_PATH를 편집하여 분리 된 빌드를 허용합니다. 어떤 빌드 시스템을 사용하든 상관 없습니다.

나는 C가 이것을 달성하는 방법에 익숙하지 않습니다. 누군가가 설명하고 연결할 수 있습니까? 이전에 무슨 일이 있었는지 https://github.com/pypa/virtualenv/blob/legacy/virtualenv.py#L1880 -L1894; 우리는 기본적으로 스크립트와 pth / egg 파일과 같은 상대적인 경로를 만들려고 노력해 왔습니다.

내 저장소도 --relocatable을 사용하고 있으며 재배치 가능한 가상 환경이 생성 된 후 스크립트를 사용하여 추가 라이브러리를 virtualenv에 복사합니다. 이를 통해 완전히 재배치 가능한 virtualenv를 생성 할 수있었습니다. 예를 들어 우리는 이것을 Windows에서 사용하고 설치 프로그램에 virtualenv를 추가합니다. 설치 후 python3 프로그램은 패키지 된 virtualenv에서 잘 작동합니다.

동일한 사용 사례는 Mac과 Linux에서도 작동합니다 ....

@ Gagi2k 거기에서하는 일은 이미 현재 재배치 가능한 구현의 취약성을 보여주었습니다. env를 완전히 재배치 할 수 있도록 만든 후 몇 가지 추가 스크립트를 수행해야했습니다. 문제는 패키지를 완전히 재배치 가능하게 만드는 방법이 대상 환경에 크게 의존한다는 것입니다. 따라서 여기서 아이디어는 virtualenv 자체가 환경을 완전히 재배치 할 수 있도록하는 것을 포기하고 (많은 경우에서 성공할 수 없기 때문에) ... 대신이 사용자 지정 스크립트를 작성하는 사람들에게 작업을 위임하여이를 달성하는 것입니다. 대상 환경에 대한 지식이있는 스크립트이므로 재배치 가능하게 만드는 데 필요한 사항과 변경 사항을 정확히 알고 있어야합니다.

사실, 공정한 요점.

내 문제는 이전에 제공 한 기능을 다시 만들고 모든 플랫폼 + 여러 배포판에서 테스트하여 이전 기능과 똑같은 작업을 수행해야한다는 것입니다.

나는 나 또는 다른 누군가가 이것을 구현할 시간을 가질 때까지 지금은 이전 virtualenv 버전을 고수하려고 노력할 것이라고 생각합니다.

@ Gagi2k virtualenv-relocate 프로젝트 아이디어에 대한 위의 의견을 참조하십시오. 다른 사람과 협력하게되어 기쁩니다. https://github.com/spotify/dh-virtualenv/ 가 좋은 출발점이 될 수 있습니다.

@bersace thx, 나는 이미 이전 코드를 복사하여 독립형 파이썬 스크립트를 만들었습니다. 지금은 드롭 인 솔루션으로 사용할 것 같지만 나중에 다른 것으로 전환하거나 내가 가지고있는 스크립트를 제공하게되어 기쁩니다.

@ Gagi2k 공유 하시겠습니까?

@bersace 아직 진행 중입니다 : https://codereview.qt-project.org/c/qt/qtivi/+/290859

전체 virtualenv 20 업데이트로 인해 예상보다 훨씬 많은 문제가 발생합니다. 스크립트를 재배치 할 수 있도록 이전 기능을 재사용하는 것은 큰 문제가 아니지만 이제 venv를 기반으로하고 pyvenv.cfg를 사용하면 훨씬 더 복잡해집니다. 예를 들어 Windows에서 오래된 virtualenv는 많은 기본 py 파일을/ lib / python(또는 심볼릭 링크). 이제 그들은 전혀 복사되지 않지만 pyvenv는 원래 위치를 가리 킵니다. 원래 위치가 업데이트되면 virtualenv가이를 처리해야하고 필요한 모든 것이 여전히 제자리에 있기를 바랍니다. 더 큰 문제는 https://bugs.python.org/issue39469 이므로 virtualenv를 재배치 할 수 있도록 모든 것을 설정하는 상대 위치를 전달하기가 어렵습니다.

지금은 pyvenv.cfg가 지원하지 않고는 할 수 있다고 생각하지 않습니다.

@gaborbernat 나는 그것이 원래 의도 한대로 virtualenv를 오용하고있을 수 있지만, 사람들이 pip를 사용하여 확장 할 수 있도록 허용하고 싶을 때 자신의 python3 사본을 애플리케이션에 제공하는 공식적인 방법은 무엇입니까?

@ Gagi2k 나는 여기서 뭔가를 놓치고 있다고 확신합니다. 하지만 주어진 시스템에서 설치 단계의 일부로 pyenv.cfg hone 만 변경할 수는 없습니까?

@gaborbernat 나는 그것이 원래 의도 한대로 virtualenv를 오용하고있을 수 있지만, 사람들이 pip를 사용하여 확장 할 수 있도록 허용하고 싶을 때 자신의 python3 사본을 애플리케이션에 제공하는 공식적인 방법은 무엇입니까?

가상 환경은 항상 컴퓨터의 일부 파이썬 인터프리터에 대한 참조가되도록 설계되었습니다. 기본 가정은 컴퓨터에 완전히 작동하는 Python 환경이 있고 별도의 site-packages 여러 개를 원한다는 것입니다. 링크를 완전히 명시 적이 지 않게 만드는 데 일부 가치가 있음을 알 수 있지만 (현재 완전히 명시적인 경로와 마찬가지로) 그 경로 를 따라가는 경우에는 끝까지 가서 pex 를 사용하여 코드를 패키징하지 마십시오. 참조를 쉽게 깨뜨리지 않고 파이썬 실행 파일을 미리?

@gaborbernat 물론 작동합니다. 가장 큰 문제는 대부분의 사용자가 설치 후 폴더 이름을 바꿀 수 있으며 계속 작동한다는 것입니다.
하지만 방금 PYTHONHOME 설정이 트릭을 수행한다는 것을 알았습니다. 최소한 원래 설치를 참조하지 않고 작동하는 Windows에서.

pex는 흥미로워 보이며 힌트를 위해 더 자세히 살펴볼 것입니다.

@gaborbernat 여전히,

@gaborbernat 물론 작동합니다. 가장 큰 문제는 대부분의 사용자가 설치 후 폴더 이름을 바꿀 수 있으며 계속 작동한다는 것입니다.

왜 그들이 이것을 기대하는지 잘 모르겠습니다. 이것은 결코 사실이 아닙니다. 재배치 가능 플래그를 사용하더라도 가능한 경우의 하위 집합에서 사실이었습니다. 따라서 v20으로 도끼가 된 이유입니다.

@gaborbernat 여전히,

@bersace 이것은 많은 사용 사례에 따라 다릅니다. deb / rpm은 Python이 대상 머신의 동일한 위치에서 사용 가능하다는 것을 보장합니까? 그렇다면 설치 중에 shebang 경로를 수정하십시오 👍

시스템 파이썬에 따라 @gaborbernat 는 파이썬이 특정 위치에 있는지 확인하기에 충분합니다.

postinst에 설치된 파일을 수정하는 것은 매우 나쁜 생각입니다. 이렇게하려면 dpkg 영역에서 모든 스크립트를 제외해야하므로 dpkg는 업그레이드시 해당 스크립트를 건드리지 않습니다. 그건 용납되지 않습니다.

AFIAK, 최상의 솔루션은 최종 패키지를 보관하기 전에 실행될 destdir 를 제거하기 위해 모든 shebangs를 편집하는 virtualenv-change-prefix 입니다.

@bersace 와

@gaborbernat 는 절대 대상 위치입니다. 예 : #!/opt/company/app/venv/bin/python .

이제 / 이외의 새 refroot에 해당 패키지를 배포하는 것이 지원되지 않습니다.

@gaborbernat 예, 의도적으로. dpkg / rpm에서 관리하는 파일은 사용자가 이동해서는 안됩니다.

이것은 relocatable 다소 다릅니다. 목적은 venv를 relative 로 만드는 것이 아니라 builddir (debian / build / ... 또는 % builddir)과 rundir (/)을 구별하는 것입니다.

우리쪽에는 실행 가능한 항목이 없기 때문에 이것을 닫습니다. 여기에서 계속 논의하거나 virtualenv에서이 문제를 해결하려는 잠재적 인 프로젝트에 대해 논의하는 것이 좋습니다.

사실, 대안은 버전 관리없이 어느 정도 공급 업체 종속성에 대한 것입니다.

필자의 경우는 분산 스파크 클러스터 내 프로그램의 실행을 지원하는 데 필요한 종속성 파이썬 패키지를 압축하여 원사에 스파크에 '아카이브'로 전달해야합니다. 이 작업은 Anaconda에서 완료 할 수 있지만 회사에서는 엔터프라이즈 소프트웨어를 사용할 수 없습니다. relocatable 은 (는) 과거에는이 문제를 해결할 수 있었지만 지금은 사라졌습니다.

제 경우에는 필요한 종속성이있는 Python 패키지를 압축하고 분산 Spark 클러스터에서 실행되는 프로그램을 지원하기 위해 Spark on Yarn에 '아카이브'로 전달해야합니다. 이 작업은 Anaconda에서 완료 할 수 있지만 회사에서는 엔터프라이즈 소프트웨어를 사용할 수 없습니다. relocatable 은 (는) 과거에는이 문제를 해결할 수 있었지만 지금은 사라졌습니다.

@jackhhh 님 , 기존 사용 사례에 대한 해결 방법을 찾았습니까?
우리는 같은 문제에 직면하고 있습니다.