야심찬 제안!

ini 구성 지원(사용자 홈에 있는 전역 ini 구성)

플랫폼 선호 위치에서 구성을 검색하려면 appdir(또는 이와 유사한 것)을 사용하는 것이 좋습니다.

appdirs는 옵션이 될 수 있지만, 우리는 패키지에 물건을 공급하는 사업을 시작해야 합니다. 공정하려면 이 중 70%가 이미 완료되었으며 더 나은 재구성이 필요합니다.

공급업체에 의존하는 것이 아니라 왜 공급업체입니까? (벤더링이 어렵다는 것이 아니라 단일 파일일 뿐입니다.) IMO, 우리는 (pip를 제외하고) 패키징 도구가 다른 애플리케이션과 마찬가지로 빌드되어야 한다는 사실을 정말로 받아들일 필요가 있습니다. 종속성을 갖는 것이 PyPA 앱이 피할 수 있을 만큼 충분히 어렵다면 사용자가 애플리케이션을 쉽게 개발할 수 있도록 우리가 얼마나 잘하고 있는지에 대해 무엇을 말합니까?

(여기서 virtualenv에 대해 큰 요점을 제시하지 않아 죄송합니다. 많은 사람들이 "PyPI 종속성을 추가하는 것은 큰 문제가 아닙니다"라고 말하는 것을 보았고, 그러면 내가 벤더링 작업을 하는 PyPA 도구가 궁금해집니다...) .

크로스 인터프리터 기능을 공급하지 않고는 어려울 것이라고 생각합니다. 예를 들어 virtualenv가 설치되지 않은 인터프리터를 위한 가상 환경 만들기.

PYTHONPATH=/t/경로/to/virtualenv.whl 파이썬 -m 가상 환경

어, 이것은 우리가 virtualenv의 추가 패키지에 의존할 수 없다는 것을 의미합니다. zipapp을 제공할 예정이므로 이를 통해 어떤 사용 사례가 가능합니까?

@gaborbernat -p 옵션을 말씀하시는 건가요? 그럴 것 같아요. zipapps가 도움이 되도록 의도된 상황과 정확히 같은 상황인 것 같습니다. 하지만 아무도 제대로 작동하도록 하는 세부 사항을 과감히 하지 않았습니다.

@pradyunsg에서 :

어, 이것은 우리가 virtualenv의 추가 패키지에 의존할 수 없다는 것을 의미합니다

사실, @gaborbernat 말대로 -p 옵션은 아마 것을 의미한다 :-( 그러나 우리가 "에 바퀴가 필요한 이유를 궁금해을 PYTHONPATH "옵션뿐만 아니라 zipapp을 - 특히 바퀴 주어진 on PYTHONPATH 는 일반적으로 지원되지 않습니다(일반적인 pip 부트스트래핑 이유 때문에 virtualenv 내에서 내부적으로 사용합니다. pip는 거의 모든 것에 대한 예외입니다 ;-))

지원 유예 기간 2년

흠...

여기서 내 걱정은 이것의 네트워크 효과로 인해 최신 버전의 Python 채택이 느려지고 지원되는 Python 수의 조합 폭발이 발생할 수 있다는 것입니다. CPython은 3.9의 다른 릴리스 주기에 대해 논의하고 있으므로 2년은 일부 릴리스가 핵심 개발자의 것보다 더 길 수도 있습니다.

즉, 나는 이것을 차단하고 싶지 않지만 대부분은 내가 이것을 하고 싶지 않다는 것을 분명히 하는 것입니다.

(언젠가 IronPython과 Jython을 기대합니다. 지원해야 할 다른 것이 있습니까?)

분명히. @gaborbernat은 아마도 내가 이렇게 말할 것이라는 것을 알고 있을 것입니다. 이것들이 있으면 좋겠지만 구현에 더 익숙한 사람들이 이것을 하기에 가장 좋은 위치에 있을 것이라고 확신합니다. 최소한 장기적인 지원 측면에서, 그리고 이상적으로는 처음부터 잘 지원되도록 하는 작업(CI, 테스트 등)입니다.

첫째, ini 구성 지원(사용자 홈에 있는 전역 ini 구성),

저는 편견이 있습니다. 저는 이것이 대신 TOML이 되는 것을 보고 싶습니다. :)

(어딘가에 가야 하기 때문에 아직 이것을 완전히 처리하지 못했습니다 -- 그러나 이것은 훌륭한 전체 목표처럼 보입니다!)

우리는 이미 교차 인터프리터 기능으로 인해 추가 패키지에 실제로 의존할 수 없으므로 이것을 주요 단점으로 생각하지 않으며 가상 환경을 실행하는 간단한 설치/종속성 없는 방법을 원합니다(사람들이 필요할 때 필요 노드 패키지에서 호출). 비용이 많이 들지 않는다는 점을 감안할 때 zipapp 외에 제공하는 것이 저렴해 보입니다.

기본 제공 venv 선호: 대상 파이썬에 venv가 있는 경우 이를 사용하여 환경을 생성합니다(그런 다음 우리가 제공하는 다른 보장을 용이하게 하기 위해 이에 대한 후속 작업을 수행합니다).

이에 대한 근거를 이해하고 있는지 잘 모르겠습니다. 그것의 유지 보수 할 것이다 것 같다 virtualenv 어렵게하고 이해하는 최종 사용자의 행동을 어렵게 만들 것입니다. setuptools 는 계속해서 원숭이 패치를 적용하기 보다는 distutils 를 흡수하려고 하여 이미 다른 방향으로 가고 있습니다.

@pganssle 범위가 다르고 문제 공간도 다릅니다. virtualenv 문제는 시스템이 종종 시스템 패키지에 추가 제약을 두므로 이를 준수하기 위해 내장된 venv를 원숭이 패치한다는 것입니다. 이 모든 것을 복제하는 것은 어려울 것입니다(예: #1362 참조).

FWIW 격리를 위해 내장된 venv 패키지를 사용하는 것이 올바른 생각이라고 생각합니다. 실제 인터프리터에 내장되어 있으므로(stdlib 모듈인 distutils가 아님) virtualenv 보다 훨씬 깨끗한 작업을 수행할 수 있습니다.

Virtualenv는 또한 아무 것도 원숭이 패치할 필요가 없으며 공개 API만 사용하면 됩니다.

FWIW 내 오래된 재작성 virtualenv 분기를 확인하는 것이 좋습니다. 이미 이러한 작업을 많이 수행했습니다.

나는 아마도 플러그인 시스템이 virtualenv에 매우 유용하지 않다고 제안할 것입니다. 기껏해야 하나의 후크, 포스트 생성 단계가 있을 가능성이 높으며 심지어 설치할 항목 목록만 있으면 벗어날 수 있습니다.

또한 "자연스럽게" 계속해서 zipapp을 사용할 수 있으며 zipapp 자체 내부에서 공급업체에 제공해야 합니다. 나는 대상 파이썬 옵션에서 재실행에서 멀어지는 것이 좋습니다. 그것은 나쁜 일이며 훨씬 더 깨끗하게 할 수 있습니다.

697 -- @dstufft 의 이전 PR

PYTHONPATH=/t/경로/to/virtualenv.whl 파이썬 -m 가상 환경

OTOH, 우리는 아마도 이것을 해서는 안 됩니다 -- https://www.python.org/dev/peps/pep-0427/#is -it-possible-to-import-python-code-directly-from- 휠 파일

@pradyunsg 그래서 경로에 바퀴를 두지 않고 핍을 부트스트랩하는 다른 방법이 있습니까?

pip 부트스트랩은 아마도 괜찮을 것입니다. 이것이 virtualenv가 지금 사용하는 것입니다 ¹ . 그러나 virtualenv 자체를 실행하는 수단이 아니라 pip 에만 사용하는 것이 좋습니다.

¹ 하지만 복잡한 기능은 피하고 싶습니다. PATH에서 휠을 사용하여 해당 휠에서 pip를 설치하는 것은 거의 문제가 없습니다. 하지만 내가 생각하는 certifi 실제 파일로 임베디드 인증서 번들이 필요합니다 (그러나 나는 나에게 문제를 일으킨 적이 없어요이 잘못 될 수 있지만 나는 알고있다, 액세스와 같은 휠을 사용하여 인터넷을, 예를 들어, 경우에 문제가있을 수 있습니다 get-pip.py 는 이 지점을 해결하기 위해 명시적으로 휠에서 인증서를 추출합니다.

pip를 zipapp 로 배송하지 않는 이유가 있습니까? 그렇게 하면 내가 이해하는 대로 이러한 필요성을 피할 수 있으며 zipapp은 python 2.7에서 지원됩니다. 🤔

@gaborbernat 해봤어? 작동합니까? 귀하가 설명한 접근 방식이 Windows에서 작동하는 경우 초기 문제는 없지만 @uranusjr 은 피드백을 @dstuff 와

pip를 zipapp으로 배송하지 않는 이유가 있습니까?

어떤 경우에는 위에서 말했듯이 pip가 zip 파일(또는 휠, 동일한 것)에서 직접 실행되지 않기 때문입니다. 시간의 99%(경고 - 구성 번호)는 작동하지만 때로는 인증서 번들이 실제 파일이어야 한다는 사실이 중요합니다.

shiv가 zipapp을 실행하기 전에 압축을 풀기 때문에 pip를 shiv 로 묶는 것이 아마도 잘 작동할 것입니다. 내가 아는 한 아무도 그것을 시도하지 않았습니다.

평소와 같이 발생하지 않은 주요 이유는 다음과 같습니다.

1. 아무도 그것에 대해 생각하지 않았습니다.
2. 아무도 그것을 할 시간/동기가 없었습니다.
3. 현재 접근 방식은 잘 작동하며 더 큰 물고기를 튀길 수 있습니다.

경로에 바퀴를 두지 않고 pip를 부트스트랩하는 다른 방법이 있습니까?

여기에서는 필요하지 않다고 생각합니다. virtualenv는 pip 휠을 사용하여 IIRC 자체에서 설치하므로 제대로 작동해야 합니다. @pfmoore가 말했듯이 get-pip.py가 하는 유일한 "추가" 작업은 인증서의 압축을 풀고 인증서에 대한 경로를 제공하는 것입니다. virtualenv의 사용 사례는 네트워크에 도달하지 않으므로 여기서 새로운 작업을 수행할 필요가 없습니다.

현재 접근 방식은 잘 작동하며 더 큰 물고기를 튀길 수 있습니다.

이것은 다른 IMO보다 훨씬 많습니다. 우리는 할 수 있지만 해결해야 할 더 영향력 있는 문제가 있습니다. :)

나는 pip를 zip 앱으로 빌드한 PR을 한 번 가지고 있었지만 작동했지만 IIRC에서는 pip가 완전히 작동하도록 변경해야 했습니다.

pip가 PEP 517에 대한 자체 하위 프로세스로 자신을 호출하기 때문에 지금은 약간 복잡할 수 있습니다. 확실하지 않지만 탐색할 가치가 있는 것은 분명합니다.

이 시점에서 shiv(또는 다른 자동 압축 풀기 옵션)는 pip를 zip 실행 가능으로 작업하는 것보다 pip에 더 적합합니다. 그러나 나는 이것이 현시점에서 특별히 중요한 것은 아니라고 생각한다. surepip은 이미 wheel-on-path 경로로 이동합니다. 그냥 똑같이 하면 안 됩니다. 더 큰 물고기를 모두 튀긴 후 대체 pip 부트스트래핑을 탐색할 수 있으며 잠재적으로 stdlib에 다시 기여할 수 있습니다.

더 큰 물고기를 모두 튀긴 후 대체 핍 부트스트랩을 탐색할 수 있습니다.

[우리가 이미 따르고 있는 계획]처럼 들립니다. ;)]

피드백을 기반으로 링크에 감사드립니다 . https://github.com/gaborbernat/virtualenv/tree/rewrite/src/virtualenv 에서 초기 작업을 시작했습니다 20.0.0 출시할 계획입니다.

존재하는 경우 venv를 사용하는 경우 +1입니다. 그러면 PyPy의 사용 사례가 더 간단해집니다.

그래서 재작성은 사람들이 그것을 보고 피드백을 주는 것이 편안하다고 느끼는 상태에 이르렀습니다. 이 일을 도와줄 자유 시간이 있으면 저에게 연락하십시오. 월말까지 출시할 계획입니다 🤞 참고 https://github.com/pypa/virtualenv/milestone/7 아직 구현해야 하지만 핵심 아이디어는 거기에 있습니다.

추신. https://github.com/pypa/virtualenv/pull/1481/ 에서 피드백 PR을 만들었습니다.

기능 요청: 사용자 지정 환경 변수를 정의하기 위한 메커니즘을 제공합니다. 예를 들어 env.txt 파일을 표준 형식으로 venv bin 디렉토리에 배치합니다.

VARNAME=value
OTHERVAR=othervalue

내가 당신의 사용 사례를 이해하지 못하는 것 같아요? 이러한 환경 변수는 언제 어떻게 사용, 설정됩니까?

편집하다. NM. https://github.com/pypa/virtualenv/issues/1124에서 확장한 것을 보았습니다

작은 업데이트; 나는 여전히 약간의 사랑이 필요한 두 가지를 제외하고 대부분의 차단 문제를 닫을 수 있었습니다. 테스트에는 헤더 포함 + 앱 데이터에 일부 잠금이 적용된 python 질문 호출 캐싱이 포함되어 있으므로 가상 환경을 병렬로(다른 위치에) 생성할 수 있습니다. 현재 속도에서는 며칠 늦을 수 있지만... 확실히 2월 7일까지 나가야 합니다.

출시 측면에서 우리의 계획은 무엇입니까? 메인 릴리스 이전에 베타 릴리스가 있습니까?

그래, 월요일에 뭔가를 내보내고 싶어... 그리고 피드백, 수정을 위해 잠정적으로 일주일을 비우고... 그런 다음 마스터를 다시 작성하고 릴리스로 바꿉니다.

일주일이면 충분할 것이라고 100% 확신할 수는 없으며 베타를 사용해 보기를 원하는 사람들이 여러 채널을 통해 확실히 소통해야 합니다.

그곳의 키워드는 잠정적으로 . 내가 들인 노력의 양을 감안할 때 나는 여기에서 낙관적이다. 나는 큰 문제를 기대하지 않지만 🤷‍♂

virtualenv 20.0.0 beta1을 사용할 수 있습니다 .

베타가 나오면서 이 문제가 목적이라고 생각합니다. 저는 이만 마치겠습니다. 전용 문제에 대해 더 집중적으로 논의할 수 있습니다.