4799는 많은 논쟁이 일어나는 곳입니다. 그것은 주로 다음과 같은 이유로 촉발되었습니다.

1. PEP 518 지원에 대한 유일한 뛰어난 차단기는 #4764(https://github.com/pypa/pip/pull/4144#issuecomment-302711736을 통해)임을 이해했습니다.
2. 그런 다음 #4799가 나타났고 @xoviat 이 하고 있는 모든 진행 중인 작업을 이해할 수 있는지 확인하기 위해 살펴보았습니다.
3. 그 과정에서 #4647이 PEP 518 지원이 중단되었다는 릴리스 차단기로 나타났습니다.

@xoviat 이 #4799에서 말한 내용을 알아내려고 하는 동안 빌드 환경의 재귀 빌드와 관련된 몇 가지 문제가 있음이 분명해졌습니다(X는 빌드에 Y가 필요하고 Y에는 Z가 필요합니다...). 이것이 구현 버그인지, 더 깊은 디자인 문제인지, 너무 많은 문제 없이 연기할 수 있는 불쾌한 코너 케이스인지에 대해서는 여전히 불분명합니다.

개인적으로 나는 내 깊이에서 벗어난 지점에 있습니다. @xoviat 의 구현이 필요한지 판단하기 위한 것인지, 아니면 #4764를 병합하고 바로 사용할 수 있도록 #4647을 수정하기만 하면 되는지 이해할 수 없습니다. 또한 #4647을 수정하는 것이 얼마나 쉬운지 나도 모릅니다( @xoviat 는 #4647을 수정하기 위해 #4799를 병합해야 한다고 말하는 것 같지만 자체 문제가 있습니다).

이번 주말에 더 이상 논의를 이어갈 시간과 에너지가 부족하여 이 시점에서 (적어도 잠시 동안은) 그만 두겠습니다. 저에게 핵심은 pip 10에 대해 수용 가능한 수준의 PEP 518 지원을 원한다는 것입니다. 누군가가 우리가 거의 다 왔는지, 아니면 몇 주 남았는지에 대한 느낌을 주어서 내가 사람들이 pip 10이 올 때까지 새해가 될 때까지 오지 않을 것이라고 해고시키는 것을 피할 수 있습니다 ...

매우 유용한 요약 @pfmoore에 감사드립니다.

@ncoghlan @dstufft @xoviat 여기에 토론을 가져도 될까요? 비공개 PR에서 하는 것은 저에게 이상하게 느껴집니다. ._.

확실한 것.

@pradyunsg 그럴 시간이 없다는 걸 압니다. 그러나 당신은 나보다 PR 승인을 받는 데 더 성공적이었습니다. 따라서 원하신다면 현재 구현, 작동 방식 및 잠재적 문제에 대해 기꺼이 안내해 드리겠습니다. 나는 이 문제들 중 일부(전부는 아님)를 어떻게 해결했는지 그리고 완전한 수정에 대한 내 아이디어를 설명할 것입니다. 나는 그것이 끝난 한 그 일을 누가 하든 솔직히 상관하지 않는다.

사실, 당신은 AWOL입니다. 그래서 요약을 작성하겠습니다.

pip 에는 대부분의 Python 프로젝트에서 흔히 볼 수 있는 것처럼 개체 계층이 있습니다. 그것은 모두 명령을 시작하여 개체에 대한 새 참조를 만들고 하위 개체에 대한 새 참조를 만듭니다. 그것은 나무와 같습니다.

객체의 "범위"를 일종의 수명으로 정의하겠습니다. 개체가 존재하는 기간입니다. 현재 pip 에 있는 PEP 518의 범위는 WheelBuilder 입니다. PEP 518 환경은 bdist_wheel 에 대해 설정되고 bdist_wheel 는 해당 환경 내에서 실행되고 환경은 해체됩니다.

그게 뭐가 문제야? 문제는 PEP 518 환경의 범위가 setup.py 에 대한 모든 호출의 범위와 같거나 커야 한다는 것입니다. 더 구체적으로 말하면 setup.py 호출 기간 동안 존재하는 개체를 캡슐화해야 합니다. 그 개체는 Requirement 입니다.

첫 번째 명백한 결정은 BuildEnvironment 에 대한 참조가 있어야 하고 Requirement 는 무엇이든 좋은 장소입니다. 실제로 Requirement 가 존재하는 경우에만 setup.py 가 호출되기 때문에 참조를 두는 것이 IMHO가 가장 좋은 위치입니다.

다음 문제는 BuildEnvironment 요구 사항을 설치하는 방법입니다. 우리는 pip 로 쉘 아웃할 수 있습니다. 그리고 그것은 원래 구현자가 내린 결정입니다. 그러나 여기에는 문제가 있습니다. pip 는 각 pip 가 자신을 다시 호출할 수 있기 때문에 얼마나 많은 쉘 호출을 하는지 알 수 없습니다. 실제로 pip 가 너무 많은 프로세스를 생성하면 순환 종속성을 포함하는 악의적으로 구성된 패키지가 누군가의 컴퓨터에 충돌을 일으킬 수 있습니다.

또 다른 문제는 우리가 어떤 쉘 호출을 해야 하는지입니다. 명령줄 매개변수를 가져오는 것이 솔직히 말해서 해당 호출을 해야 하는 PITA이기 때문에 실제로는 생각보다 까다롭습니다. 따라서 사용자가 자식에게 전달한 원래 매개변수를 전달하는 데 문제가 있을 수 있습니다. 원래 구현자가 사용한 솔루션은 finder 을 사용하는 것과 관련이 있지만 그 문제를 알고 있다고 생각합니다.

사용자가 ctrl+C를 누를 때 어린이를 죽일 수 있는 일종의 관리자 클래스 없이 자신의 자식을 제거하는 것은 잘못된 것이 아니라 악의적입니다. 특히 생성한 프로세스의 수를 모르는 경우에는 더욱 그렇습니다. 나는 개인적으로 아이들이 현재 구현에서 죽는지 여부를 모르지만(이것은 FUD일 수 있음), 그렇지 않다면 현재 구현 IMHO가 잘못된 것입니다(다른 문제 제외).

해당 문제에 대한 몇 가지 가능한 솔루션은 다음과 같습니다.

1. PEP 518을 밖으로 내보내고 싶다면 가장 좋은 방법은 아마도 최대 10개 정도의 잠금만 허용하는 일종의 잠금 파일일 것입니다. 그런 다음 명령줄 인수와 함께 정확한 요구 사항을 자식에게 전달할 수 있습니다.

2. PEP 517 이후에 구현하고 싶은 적절한 솔루션은 install 명령에서 직접 초기화되는 BuildEnvironmentManager 클래스를 갖는 것입니다. BuildEnvironmentManager 는 거기에 있는 모든 객체( RequirementPreparer , WheelBuilder 등)에 대한 참조를 가지며 get_build_environment(requirement_set) 단일 메서드를 갖습니다. 그런 다음 set_build_environment_manager 와 같은 $ RequirementPreparer 메서드를 구현하여 빌드 환경을 얻을 수 있습니다. BuildEnvironmentManager 는 동일한 환경(가장 일반적으로 ['setuptools', 'wheel'] )을 여러 번 사용하는 것을 감지하고 여러 번 필요한 경우 동일한 환경을 제공하여 생성할 필요가 없도록 할 수 있습니다(초기에는 매우 일반적입니다 . pyproject.toml 가 없는 프로젝트 포함). 이상적으로는 순환 참조(사소하지 않음)를 제거하려고 시도하는 일부 OOP 디자인도 있을 것입니다.

@xoviat --no-binary :all: 인 악의의 경우는 다루지 않을 수 있지만 완료된 빌드뿐만 아니라 -progress 것, 빌드 종속성 주기가 종료되도록 하는 것으로 충분합니까? 이것은 첫 번째 제안(동시 pip 호출 수에 대한 프로세스 간 제한)의 변형이지만 다음과 같이 다시 작성됩니다.

1. 한 시스템의 한 프로세스만 동시에 동일한 패키지를 빌드할 수 있습니다.
2. pip가 생성하는 모든 하위 빌드로 전달하는 최상위 "빌드 ID"가 있습니다(예: 빌드 중인 패키지의 이름과 결합된 최상위 프로세스의 PID).
3. 빌드 캐시가 다른 빌드 ID로 빌드 중임을 나타내는 경우 해당 빌드가 완료될 때까지 기다립니다.
4. 빌드 캐시가 동일한 빌드 ID에 대해 이미 빌드 중임을 나타내는 경우 순환 종속성을 보고하고 빌드가 작동하려면 --binary <name> 가 필요함을 나타내는 오류로 구제합니다.

pip 는 setuptools 와 wheel 이 모두 필요한 기본 논리에서 setuptools & wheel 를 제외하는 @pfmoore 제안을 구현해야 합니다. wheel 를 빌드 종속성으로 사용하지 않으면 암시적 빌드 종속성 주입이 본질적으로 순환 종속성 감지 논리를 트리거합니다.

디스크를 사용하여 OOP 설계 문제를 파악하지 않아도 되는 것은 나쁜 생각이 아닙니다. 이는 PEP 518을 완전히 올바르게 구현하는 것과 무언가를 함께 해킹하는 것 사이의 중간 옵션과 같습니다.

또한 운영 체제 수준 도구를 사용하여 서로 다른 Python 수준 빌드를 서로 격리할 수 있으므로 컨테이너화된 환경 및 chroot와 원활하게 상호 작용할 수 있으므로 pip는 자체 하위 프로세스를 보장하는 방법을 파악하면 됩니다. 서로 협력합니다.

@xoviat 위의 요약에 감사드립니다. 내가 말했듯이, 나는 이 분야의 코드에 대한 나의 이해의 한계에 도달했고, 당신의 설명은 나에게 엄청난 도움이 되었습니다.

나는 실제로 #4144의 코드를 본 적이 없었다. 방금 했는데 배송되는 것을 정말 원하지 않습니다.

PEP 518을 완전히 올바르게 구현하고 무언가를 함께 해킹하는 것입니다.

솔직히 여기까지 온 것 같아요. PEP 518을 완전하고 적절하게 구현하는 것은 그렇게 하면 pip 10을 (공정한) 비트로 지연시킬 수 있는 작업입니다.

여기에서 안전한 중간 지점은 빌드 종속성을 바퀴로 사용할 수 있도록 요구하는 것입니다. 그렇게 하면 빌드 종속성(및 모든 종속성)이 이 프로세스를 통해 빌드될 필요가 없기 때문에 재귀 문제를 피할 수 있습니다.

어떻게 들리나요?

그것은 제한적이지만 제한된 첫 번째 구현이 조심하지 않으면 발에 쏘일 수 있는 첫 번째 구현보다 낫다고 생각합니다.

PEP 518을 완전하고 적절하게 구현하는 것은 그렇게 하면 pip 10을 (공정한) 비트로 지연시킬 수 있는 작업입니다.

확인해주셔서 감사합니다. 그게 제 두려움이었습니다.

그러나 적어도 부분적인 PEP 518이 이미 마스터에 있다고 생각 했기 때문에 지금은 혼란스럽습니다. 특히, 내가 이해한 대로 #4647은 마스터의 PEP 518 지원에 있는 버그를 보여줍니다.

그래서 우리는 뭔가를 해야 하고 옵션은 다음과 같습니다.

1. 현재 PEP 518 지원을 위해 가지고 있는 모든 것을 제거하십시오.
2. 우리가 가진 것을 정리하고 부분 지원을 제공하십시오.
3. pip 10을 릴리스하기 전에 PEP 518을 완전히 구현하십시오.

당신이 말했듯이 (3)은 pip 10 이전의 긴 지연을 의미하며 우리는 정말로 릴리스되었으면 하는 다른 수정 사항이 있습니다(유니코드 수정은 우리가 정기적으로 문제를 해결하는 것입니다). 그래서 나는 그것에 관심이 없습니다. 당신은 (1)을 언급하지 않았고, 그것이 우리가 PEP 518 지원이 없다고 생각했기 때문인지 아니면 당신이 그것을 철회하는 것이 옵션이 아니라고 생각했기 때문인지 확실하지 않습니다. 개인적으로 나는 그 아이디어가 마음에 들지 않습니다. 그것은 후진적인 단계이며, 올바르게 구현하기 어려운 경우 PEP 자체에 대해 상당히 부정적인 메시지를 보냅니다. 그러나 나는 우리가 그것을 거부하는 것에 대해 분명히 해야 한다고 생각합니다.

휠을 빌드 종속성으로만 지원하는 PEP 518 버전을 출시한다는 (2)에 대한 귀하의 제안(휠인 빌드 종속성을 사용하는 데모이므로 #4647을 수정해야 함)이 합리적으로 보입니다. , 우리가 구현하는 것이 실용적이라는 의미에서. 나의 주된 유보는 그 제한이 PEP 518을 사용하려는 사람들에게 얼마나 문제가 될 것인지 전혀 모른다는 것입니다.

그래서 저는 우리가 무엇을 하든 막힌 것 같지만 빌드 종속성으로 바퀴만 부분적으로 지원하는 것이 나쁜 선택 중에서 가장 좋은 선택이라고 생각합니다.

PEP 작성자(https://github.com/pypa/pip/pull/4799#issuecomment-338331267 및 https://github.com/pypa/pip/pull/4799#issuecomment-338332575에서 내 질문에 대한 답변) https://github.com/pypa/pip/pull/4799#issuecomment-338325354) 그러나 완전한 PEP 지원을 위해서는 빌드 종속성을 구축해야 하므로 임시방편일 뿐이라는 점은 매우 확실합니다.

그러나 이것을 구현하는 것은 내가 아니므로 누가 수행하는가의 판단에 따라가게 되어 기쁩니다. 내가 한 한 가지는 #4803을 만들고 이를 릴리스 블로커로 표시하는 것입니다. 필요한 경우 사양에서 벗어나는 방법을 문서화해야 한다는 점을 상기시켜줍니다.

(그리고 이 문제에 대해서는 주제를 벗어났지만 PEP 517 구현을 시작할 때 같은 실수를 하지 않도록 조심하라고 제안할 수 있습니까? 코딩에 너무 깊이 들어가기 전에 구현의 모든 의미를 이해했는지 확인합시다 - 내 본능 PEP 517은 PEP 518보다 훨씬 더 복잡한 설계 문제가 될 것입니다...)

저는 "소스에서 모든 것을 빌드" 관점에서 배포판에 가장 익숙하며 "빌드루트 부트스트랩" 프로세스를 일반 패키지 빌드 프로세스와 확실히 분리합니다. 소스에서 완전 자동 부트스트랩은 어렵 습니다. 결국 C 컴파일러를 부트스트랩하는 것과 같은 작업을 수행해야 하기 때문입니다.

따라서 pip의 경우 빌드 종속성은 항상 휠 파일에서 설치할 수 있다고 말하는 것이 합리적이라고 생각합니다. 10.x 이후에 도입할 수 있는 개선 사항은 일반 휠 캐시와 구별되는 빌드 캐시를 사용하여 캐시 사용자가 PyPI에서 다운로드하는 것이 아니라 제어된 환경에서 빌드된 모든 휠을 확인할 수 있도록 하는 것입니다. 또는 다른 인덱스 서버.

개인적으로 나는 그 아이디어가 마음에 들지 않습니다. 그것은 후진적인 단계이며, 올바르게 구현하기 어려운 경우 PEP 자체에 대해 상당히 부정적인 메시지를 보냅니다.

나는 그것에 반드시 동의하는 것은 아니다. pip에 대해 올바르게 구현하기가 어렵습니다. 그러나 PEP에 명시된 바와 같이 pip는 사람들이 사용할 유일한 프론트 엔드 중 하나입니다. 저는 언어 구현자로서 우리의 일이라고 생각하고, pip는 실제로 사람들이 파이썬 프로젝트를 패키지하는 데 사용하는 언어로, 이러한 모든 어려운 문제에 대해 생각할 필요 없이 빌드 시스템을 가능한 한 간단하게 생성할 수 있도록 합니다. 그들에게는 우리가 열심히 일했기 때문에 원활하게 작동해야 합니다.

여기에서 안전한 중간 지점은 빌드 종속성을 바퀴로 사용할 수 있도록 요구하는 것입니다.

실제로 이것이 #4799가 하는 일입니다. 원하는 경우 해당 분기를 복원한 다음 분기하여 PR로 제출할 수 있습니다.

@xoviat 이 위에서 지적했듯이 (2)의 구현 측면에서 두 가지가 여전히 존재합니다.

1. 하위 프로세스를 만드는 방법 파악하기(인수 외)
   할 수 있어야 한다고 생각합니다.

2. 설치할 패키지 버전.
   이것은 현재 리졸버 코드가 여전히 pip._internal.operations.prepare 의 코드와 얽혀 있다는 사실을 감안할 때 정확히 어떻게 일어날지 확신할 수 없지만 동일한 부모 프로세스에서 수행되어야 합니다. 이번 주에 한 번 살펴보겠습니다.

누가 이런 일을 할 시간이 있을지 모르겠습니다.

올바르게 구현하기 어려운 경우 PEP 자체에 대한 매우 부정적인 메시지를 보냅니다.

아마도 올바르게 구현하는 것은 어렵지 않을 것입니다. 그것은 단지 pip의 코드베이스가 오늘날과 같은 방식으로 pip에서 구현하는 것이 사소하지 않다는 것입니다. 이상한 장소에서 일어나는 일들이 있고 그것이 정리된다면 상당히 사소할 것이라고 생각합니다.

당신은 (1)을 언급하지 않았고, 그것이 우리가 PEP 518 지원이 없다고 생각했기 때문인지 아니면 당신이 그것을 철회하는 것이 옵션이 아니라고 생각했기 때문인지 확실하지 않습니다.

나는 물러나는 것이 선택사항이 아니라고 생각했다.

지금 생각해보니 PEP 518을 pip 10으로 배송하는 것이 얼마나 중요한가요? 다음 메이저 릴리스로 연기할 수 있다면 (이 상황에서 쉽게 벗어날 수 있는 방법이 아닌) 간단하고 517 + 518 모두 하나의 큰 릴리스에 포함될 수 있다고 생각합니다. 이것은 내가 갈 길이 아니라고 말하는 사람이 없을 정도로 충분히 깨끗하다고 ​​느껴집니다.

@dstufft @xavfernandez 생각?

@ncoghlan 의 빌드 캐시에 대한 아이디어는 나에게 좋은 생각처럼 들립니다. 비록 내가 모든 의미를 이해하고 있는지 확신할 수는 없지만.

원하는 경우 해당 분기를 복원한 다음 분기하여 PR로 제출할 수 있습니다.

나는 아마도 시간이 없을 것이고 내가 한다 해도 기존 커밋을 재사용하지 않을 것입니다. 그러나 해당 분기를 복원하는 것은 문제가 되지 않습니다. :)

나의 주된 유보는 그 제한이 PEP 518을 사용하려는 사람들에게 얼마나 문제가 될 것인지 전혀 모른다는 것입니다.

우리는 당신이 아마 그것을 모르고 있었다는 점을 제외하고는 이 정확한 토론을 했습니다. 이 상황은 X 상황입니다. 빌드 환경이 설정되기 전에 egg_info를 호출하는 것은 상황 Y(#4799)입니다.

그러나 이것을 구현하는 것은 내가 아니므로 누가 수행하는가의 판단에 따라가게 되어 기쁩니다.

그렇다면 #4799가 다시 테이블 위에 있다는 뜻인가요? 모든 테스트를 통과하고 원하는 작업을 수행하는 한?

아아, 그 X와 Y가 다시 나를 괴롭히기 위해 돌아왔다 :윙크: 예, 나는 두 가지 경우의 상대적 가능성에 대해 느낌이 없다는 말을 하고 있습니다. 바퀴가 아닌 빌드 요구 사항이 매우 드물기 때문에 해당 사례를 무시해도 된다는 말씀을 이해합니다. 기본적으로 우리 사이에 "괜찮다"는 한 표와 "모르겠다"는 한 표가 있었습니다. 나는 이 옵션을 막으려는 것이 아니라 단지 내 직관의 한계가 어디인지 말하는 것뿐입니다.

@xoviat 몇 가지 질문이 있습니다. 새로운 PR을 하기 전에 답변을 해주시면 정말 좋을 것 같습니다. :)

• 어떤 패키지가 설치될지 어떻게 결정하시겠습니까?
• 바이너리 전용 빌드 종속성으로 제한하시겠습니까?

나는 많은 과학 프로젝트와 함께 일했기 때문에 편견이 있을 수 있습니다. 그러나 휠 빌드 종속성이 있는 프로젝트 목록에서 덜컥거릴 수 있고 소스 종속성이 있는 한 프로젝트를 진정으로 생각할 수 없습니다. 내가 틀렸을 수도 있습니다.

@rgommers 다음 pip에 있는 경우 휠로 사용할 수 있는 빌드 종속성만 지원하는 PEP 518을 사용하시겠습니까?

어떤 패키지가 설치될지 어떻게 결정하시겠습니까?

하위 프로세스는 지정된 대로 정확히 요구 사항 목록을 가져옵니다. 그런 식으로 리졸버를 통과합니다.

바이너리 전용 빌드 종속성으로 제한하시겠습니까?

네, 사실 이것이 테스트가 실패한 이유입니다. 테스트의 빌드 종속성은 휠이 아닙니다.

지금 생각해보니 PEP 518을 pip 10으로 배송하는 것이 얼마나 중요한가요? 다음 메이저 릴리스로 연기할 수 있다면 (이 상황에서 쉽게 벗어날 수 있는 방법이 아닌) 간단하고 517 + 518 모두 하나의 큰 릴리스에 포함될 수 있다고 생각합니다. 이것은 내가 갈 길이 아니라고 말하는 사람이 없을 정도로 충분히 깨끗하다고 ​​느껴집니다.

pip 11에 대해 PEP 517 및 518을 수행할 시간이 있는 사람을 얻을 수 있는지 여부에 대한 느낌은 어떻습니까? 나는 낙관적이지 않다. 제 생각에는 둘 다 큰 작업 덩어리인 것 같으며 해결 프로그램 작업도 진행 중입니다. 나는 10핍을 필요 이상으로 오래 유지하는 것을 찬성하지 않지만 본질적으로 부수적인 릴리스 시리즈를 출시하는 동안 모든 주요 기능 계획이 표류하는 것 역시 불편합니다.

다시 말해서 "pip 10 릴리스를 위해 가자"는 말은 PEP 518 작업에 대한 활동의 ​​부활을 촉발했습니다. pip 10에서 이를 제거하면 릴리스 준비에 집중할 것이며 PEP 518이 다시 추진력을 잃을 가능성이 있다고 생각합니다. 다시 활동을 시작하려면 무엇을 해야 할까요? @xoviat 는 구현 작업을 하고 있지만 나머지 사람들이 지금까지 그가 겪고 있는 문제를 이해하도록 하는 데 문제가 있었습니다. 다시는 피드백 없이 일하게 하고 싶지 않습니다.

우리가 할 수 있는 일은 우리가 준비한 증분 수정으로 "pip 9.1"을 출시하고 파이프라인에 있는 3가지 큰 티켓 기능(최소한 하나)의 구현을 위해 버전 번호 "pip 10"을 예약하는 것입니다. 하지만 그렇게 하면 2018년 1분기에 pip 10 릴리스를 약속하려고 합니다. [1] 접근 방식으로 괜찮습니다. 그러나 현재 마스터에서 부분적으로 지원을 철회하는 것과 관련하여 무엇이 관련될지 아는 사람이 있습니까? 또는 우리가 가지고 있는 것과 그 한계가 무엇인지 문서화할 때(사람들이 완전한 것으로 가정하여 그것을 사용하려고 하지 않도록, 버그를 일으키고 우리가 응답해야 하는 문제를 제기해야 합니다. "이 기능은 아직 완료되지 않았습니다. 죄송합니다. 10")? 우리는 단지 하나의 큰 작업 덩어리를 다른 작업으로 교환하고 있습니까?

[1] 자원이 극히 제한된 자원으로 가능한 모든 일에 전념할 수 있는 범위 내에서.

나는 많은 과학 프로젝트와 함께 일했기 때문에 편견이 있을 수 있습니다.

감사합니다. 때때로 사람들의 배경을 알기가 어렵습니다. 과학 프로젝트에 대해 잘 알고 계시다면 제 걱정을 많이 덜어드릴 수 있을 것입니다.

우리가 할 수 있는 일은 우리가 준비한 증분 수정으로 "pip 9.1"을 출시하고 파이프라인에 있는 3가지 큰 티켓 기능(최소한 하나)의 구현을 위해 버전 번호 "pip 10"을 예약하는 것입니다.

나는 이것을 정말로 좋아한다. 핍 10.0.0 대신 핍 9.1.0에 +1

2018년 1분기에 pip 10 릴리스를 약속하려고 합니다. [1] 접근 방식으로 괜찮습니다.

나는 매우 흥미로운 아이디어를 가지고 있었습니다. 2018년 10월 12일에 pip가 10살이 되었습니다. 그때가 pip 10.0.0 릴리스를 하기에 완벽한 날짜가 될 것입니다. 완전히 다른 타임라인입니다. 나는 우리가 그 때까지 흰 고래 기능을 연기해야 ​​한다고 말하는 것은 아니지만 내 일부는 이 버전 번호와 나이도 일치하기를 정말로 원합니다.

나는 PEP 518이 다시 추진력을 잃을 가능성이 있다고 생각합니다.

되지 않도록 최선을 다하겠습니다. @xoviat 도 기꺼이 그렇게 해주길 바랍니다. :)

현재 마스터에 있는 부분 지원을 철회하는 데 무엇이 관련될지 아는 사람이 있습니까?

나는 내일 이것을 살펴보는 것에 신경쓰지 않을 것이다. @dstufft 가 #4144에서 검토된 사람이었기 때문에 이에 대한 그의 의견이 가치 있다고 생각합니다.

참고 - @dstufft 및 @xavfernandez 의 동의 없이 일을 철회하는 것만큼 과감한 일은 하고 싶지 않습니다. 따라서 그들이 말하는 내용도 살펴보겠습니다.

@dstufft 는 하루 중 시간이 충분하지 않습니다. 그는 또한 창고가 무너지지 않도록 해야 합니다.

그들이 무슨 말을 하는지도 봅시다.

예, 부탁합니다. :)

UX 관점에서: "신뢰하는 신뢰" 공격에 포괄적으로 대응하는 것은 정말 고통스럽고 [1] "나는 소스에서 모든 것을 컴파일합니다"라고 말하는 많은 사람들이 실제로 그렇게 하지 않는다는 것을 알게 될 것입니다. 다른 사람이 제공한 바이너리(예: 런타임 환경 및 운영 체제 공급자의 빌드 도구 체인) 또는 이전 세대 자체 플랫폼(예: 새 버전의 Fedora 및 RHEL은 이전 버전의 Fedora 및 RHEL에서 시드되며 처음부터 완전히 시작되지는 않습니다. Gentoo와 같은 소스 기반 Linux 배포판도 설치 프로그램으로 시작하여 Linux 커널, C 컴파일러, 하드웨어 드라이버 등이 있는 작업 빌드 환경을 제공합니다.

따라서 pip 10이 --no-binary :all: 가 종속성을 빌드 하지 않고 런타임 종속성에만 적용된다고 말하는 것이 완전히 합리적이라고 생각합니다. 사람들이 소스에서 명시적으로 빌드루트를 구성하려는 경우에도 여전히 할 수 있습니다. 빌드 종속성에 대한 암시적 소스 빌드를 허용하는 것과 관련된 고유한 재귀 부트스트래핑 문제로 인해 pip 10이 이를 암시적으로 자동화하지 않을 뿐입니다.

사람들이 빌드 환경이 완전히 사전 구성될 것으로 예상한다고 표시할 수 있도록 하려면 소스 빌드의 일부로 암시적 바이너리 부트스트랩이 필요한 경우 설치가 완전히 실패하도록 별도의 --no-implicit-builddeps 옵션을 추가하는 것이 합리적입니다. . 그렇게 하면 모든 것이 소스(빌드 종속성 포함)에서 빌드되도록 하려는 사람들이 다음과 같은 작업을 수행할 수 있습니다.

pip install --no-binary :all: --no-implicit-builddeps -r build-requirements.txt
pip install --no-binary :all: --no-implicit-builddeps -r requirements.txt

그리고 첫 번째 그룹이 CPython 및 사전 설치된 비-Python 빌드 도구 체인 외에 다른 것이 필요하지 않은 지점에 도달하는 데 필요한 만큼의 고유한 설치 그룹을 정의합니다.

이 개념에 대한 잠재적인 미래 보완은 사람들이 격리된 환경에서 각 빌드를 수행하는 대신 필요한 소스 빌드에 사용할 사전 구성된 빌드 환경을 지정하기 위해 --buildenv <path> 라고 말할 수 있게 하는 것입니다. 그러나 나는 그것을 pip 10에 넣으려고 시도하지 않을 것입니다 - 10.x를 "바이너리 빌드 종속성이 허용됨"의 행복한 경로와 "바이너리 빌드 종속성이 필요한 경우 빌드 실패"의 대체 옵션으로 제한하는 것이 좋습니다. 현재 실행 중인 인터프리터에서 이미 사용할 수 없습니다."

[1] https://www.schneier.com/blog/archives/2006/01/countering_trus.html

나는 합리적으로 보이고 너무 많은 리팩토링이 필요하지 않은 다른 옵션을 생각했습니다. 기본적으로 멀티 스레딩을 사용하여 빌드 환경이 설정되는 동안 기본 스레드를 보류 상태로 두는 것입니다. 아이디어는 다음과 같습니다. install.py 에는 BuildEnvironmentManager 가 있습니다.

class BuildEnvironmentManager(Thread):
    '''Has references to literally everything (cache, resolver, etc.)'''
    def run(self):
        while True:
            requirement_list, future = self.build_environment_queue.get()

            # install the requirements using all of the things
            # that we have

            # then put the build environment in the future
            future.put(BuildEnvironment())

그러면 다른 파일이 생깁니다. (나는 backend.py가 충분하지 않고 아마도 더 많은 것을 사용할 수 있기 때문에 backend.py를 사용합니다. 그리고 그것은 트리의 맨 아래에 있습니다):

class Future(Queue):
    pass

class BuildEnvironmentQueue(object):
    def __init__(self):
        self._queue = Queue()

    def request_build_environment(self, requirement_list):
        f = Future()
        self._queue.put((requirement_list, f))
        return f.get()

    def get():
        return self._queue.get()

그리고 operations/prepare.py에서:

# This call will put the thread to sleep until we have a build environment
# with the requirements installed
self.build_environment_queue.request_build_environment(requirement_list)

이것은 최소한의 리팩토링이 필요하고 직렬화된 BuildEnvironmentManager 를 갖고(따라서 빌드 환경을 최적화할 수 있고 단일 개체에서 수행된 요청이 무엇인지 정확히 알 수 있음) 모든 것을 하나의 프로세스에 포함할 수 있다는 장점이 있습니다. 최악의 시나리오는 교착 상태입니다). 물론 다른 스레드에 대해서는 로깅을 비활성화해야 하지만 그다지 문제가 되지는 않습니다.

queue.Queue 기반 접근 방식에 대한 내 질문에 답하기: Python 2.7에서 https://pypi.org/project/futures/ 를 공급해야 하므로 동시.futures에 의존하지 않는 것이 가장 좋습니다.

pip 코드 기반을 잘 알지 못하더라도 빌드 환경 관리를 한 곳에서 통합한다는 개념은 여전히 ​​매력적인 옵션처럼 보입니다.

concurrent.futures 는 해당 접근 방식에 필요하지 않습니다. Future 는 더 설명적인 래퍼입니다.

필요한 기본 요소는 대기열입니다: https://docs.python.org/2/library/queue.html

이 줄 을 BuildEnvironmentManager 로 이동할 수 있습니다.

나는 많은 과학 프로젝트와 함께 일했기 때문에 편견이 있을 수 있습니다. 그러나 휠 빌드 종속성이 있는 프로젝트 목록에서 덜컥거릴 수 있고 소스 종속성이 있는 한 프로젝트를 진정으로 생각할 수 없습니다. 내가 틀렸을 수도 있습니다.

글쎄, 하나는 [Windows, macOS, Linux]가 아닌 모든 OS가 있습니다. IIRC는 manylinux1 대상이 아닙니다.

@rgommers 다음 pip에 있는 경우 휠로 사용할 수 있는 빌드 종속성만 지원하는 PEP 518을 사용하시겠습니까?

제 부름은 아니지만 여기에서 한 걸음 더 나아가면 기쁠 것입니다. 어쨌든 PEP 518 지원은 선택 사항이므로 pip 10에서 바퀴를 사용할 수 있을 때만 작동합니다(내가 말할 수 있는 경우의 90% 이상 포함). 여전히 상당한 개선입니다.

PyPI에서 휠을 허용하지 않는 플랫폼에도 여전히 로컬 휠 캐시가 있습니다. 즉, pip가 암시적 으로 작업을 부트스트랩할 수 없더라도 여전히 출력하고 "이 빌드 종속성을 어떻게든 설치하세요. , 그러면 작동합니다."

그러나 현재 마스터에서 부분적으로 지원을 철회하는 것과 관련하여 무엇이 관련될지 아는 사람이 있습니까?

나는 이것을 조사했다. 너무 힘들지 않은 것 같습니다. 우리가 이 길을 가기로 결정한다면 기꺼이 홍보하겠습니다.

핍 10.0.0 대신 핍 9.1.0에 +1

마침내 distutils-sig 스레드를 제대로 읽고 관련 PR 및 토론(#4351, #4144, #4799 및 기타)을 볼 시간이 생겼습니다. 이제 우리가 pip 10을 발표한 이후로 생각합니다. 그것이 우리가 해야 할 일입니다. 부분적인 PEP 518 지원(9.1.0 없음)을 사용합니다.

이 버전 번호와 나이가 일치해야 합니다.

버머. :(

@ncoghlan 어쩌면 이 댓글이 레이더 아래로 미끄러졌을 수도 있습니다 -- https://github.com/pypa/pip/pull/4799#issuecomment -338416543

그렇지 않은 경우, 나는 그런 종류의 설정을 이해하고 그것에 대해 더 많이 배울 준비가 되어 있기 때문에 작동하지 않는 이유를 설명할 수 있다면 좋을 것입니다. :)

@pradyunsg 빌드 캐시 아이디어의 특정 구현이기 때문에 대부분 작동한다고 생각합니다. 여기에서 다루지 않는 한 가지 측면은 빌드 종속성 루프입니다. "이미 빌드하려는 것을 빌드하라는 요청을 받았습니다"를 감지하는 방법이 없기 때문입니다.

pip는 종속성 루프를 마술처럼 해결할 필요가 없습니다. 실제로 무한 루프에 들어가는 것이 아니라 이를 감지하고 발견하는 즉시 실패하면 됩니다.

종속성 루프를 빌드하는 것은 다루지 않습니다.

바이너리 전용 빌드 종속성에서는 발생하지 않습니까?

@pradyunsg 링크된 주석은 빌드 종속성에 대한 소스 빌드를 허용하는 방법에 대한 것이었습니다. 즉, 순환 종속성이 잠재적인 문제가 된다는 의미입니다. 바이너리 종속성이 필요한 경우 pip 는 당분간 기존 휠 캐시에 의존할 수 있습니다.

아 맞다. 감사 해요! :)

저는 부분 PEP 518 구현이 바이너리 빌드 종속성으로 제한되어 있는 pip 10에 찬성합니다(또는 pip 휠 캐시에서 이미 사용 가능한 경우).

아직 전체 스레드를 읽지는 않았지만 바이너리 빌드 종속성으로 제한하는 한 가지 부작용은 많은 경우에 빌드 dep에 C 종속성을 갖는 것이 ~불가능하다는 점을 지적하고 싶습니다. 예, Windows, macOS 및 일부 Linux 버전에는 바이너리 휠이 있지만 다음에는 없습니다.

• glibc를 사용하지 않는 모든 Linux(Docker 내부의 Alpine Linux가 널리 사용됨).
• FreeBSD 등과 같이 Linux가 아닌 모든 *nix 운영 체제

이는 예를 들어 모든 CFFI 기반 프로젝트가 PEP 518을 사용할 수 없거나 해당 플랫폼에서 제거할 수 있음을 의미합니다.

이것은 이미 제기되었을 수 있습니다! 나중에 이 스레드를 읽을 것입니다.

@dstufft 맞습니다. 그러나 우리가 제안하는 것은 pip 캐시를 사용하는 것이 옵션이라는 것입니다. 따라서 먼저 빌드 종속성을 pip wheel 또는 pip install 하면 캐시에 저장됩니다.

이것은 이미 제기되었을 수 있습니다!

아니요. :)

이는 예를 들어 모든 CFFI 기반 프로젝트가 PEP 518을 사용할 수 없거나 해당 플랫폼에서 제거할 수 있음을 의미합니다.

물론. :-(

이 문제를 해결하는 방법은 PEP 518 동작을 옵트인으로 만들 수 있다는 것입니다. pyproject.toml 파일이 있으면 격리 + 빌드 환경을 사용하고 그렇지 않으면 setup.py 을 사용하는 현재 동작으로 폴백합니다.

나중에 이 스레드를 읽을 것입니다.

제발. :)

나는 Donald와 똑같은 말을 했습니다. 이 스레드에 대한 내 이해는 바이너리 전용은 pip 10에 대해 구현할 시간이 없기 때문에 일시적이라는 것입니다. 맞습니까?

대신 영구 결정으로 제안된 경우 물론 -1입니다.

나는 Donald와 똑같은 말을 했습니다. 이 스레드에 대한 내 이해는 바이너리 전용은 pip 10에 대해 구현할 시간이 없기 때문에 일시적이라는 것입니다. 맞습니까?

맞습니다. pip 는 소스 종속성을 지원해야 하지만 인력이 부족합니다.

이 문제를 해결하는 방법은 PEP 518 동작을 옵트인으로 만들 수 있다는 것입니다. pyproject.toml 파일이 있는 경우 격리 + 빌드 환경을 사용하지 않으면 setup.py를 사용하는 현재 동작으로 폴백합니다.

나는 이 댓글을 다시 읽었고 여기에 동의하지 않을 것입니다. PEP 518 지원은 선택 사항이 아니어야 합니다(PEP 517과 관련된 구현 이유 때문에) IMHO, 하지만 이러한 플랫폼에서 프로젝트를 제거할 수 없어야 합니다.

더 구체적으로 말하면, 설치하려는 특정 프로젝트가 PEP 518을 얻을 수 있는지 여부를 결정해서는 안 됩니다. 이는 빌드 종속성을 휠로 사용할 수 있는지 아니면 캐시에서 사용할 수 있는지에 따라 결정되어야 합니다. 또한 다음과 같은 메시지를 뱉어내면 해당 플랫폼에서도 PEP 518 지원을 필수로 설정할 수 있습니다.

Error: build dependency X is not in the pip cache. Run "pip install X" before installing Y.

내 자신의 관점을 요약하면:

1. 저는 "빌드 종속성에 대한 암시적 빌드 지원 없음"을 pip 10의 임시 제한으로 간주하여 특정 클래스의 문제(예: 빌드 종속성 루프)를 기능의 첫 번째 릴리스된 반복에서 만날 수 없도록 합니다. 플러그인 가능한 빌드 백엔드 지원의 향후 반복은 빌드 종속성에 대한 암시적 소스 빌드를 허용하는 동시에 허용하면 발생하는 새로운 문제를 피하기 위해 적절한 조치를 취할 수 있습니다.
2. 실제로 빌드를 암시적으로 실행하지 않고 오류 메시지에서 관련 python -m pip wheel X Y Z 명령을 내보내는 것이 현재로서는 적절한 해결 방법입니다. 이는 pip가 실수로 머신 폭탄을 분기할 수 없도록 하기 때문입니다.
3. 빌드되는 특정 휠에 pyproject.toml 파일이 있거나 격리된 빌드가 명령줄에서 명시적으로 요청 되지 않는 한 격리된 빌드는 아직 기본값이 아니어야 합니다. 이는 기존 프로젝트가 격리되지 않은 동작을 예상하기 때문에 이전 버전과의 호환성 문제입니다. 격리된 빌드를 릴리스 또는 두 개에 사용할 수 있고 사용성 문제가 해결되면 일반적으로 기본이 될 수 있습니다(암시적으로 격리된 빌드를 생성하는 대신 사용할 특정 빌드 환경을 지정하는 명령줄 옵션이 있을 수 있음). 것)

@ncoghlan 주의 사항: 기본 빌드 격리가 없다는 것은 PEP 517이 없음을 의미합니다(적어도 제 접근 방식에서는) 최신 버전의 setuptools만 지원하기 때문에 컴퓨터). 실제로 나는 PEP 517을 구현하는 데 필요한 노력의 양을 극적으로 증가시킬 것이기 때문에 PEP 517을 적어도 1년 연기할 수 있다고 생각합니다(PEP 517 및 비PEP 517 코드 필요).

이는 기존 프로젝트가 격리되지 않은 동작을 예상하기 때문에 이전 버전과의 호환성 문제입니다.

대부분의 사람들은 pip install X 를 실행한 다음 pip install Y 를 실행하는 CI 스크립트를 가지고 있습니다. 이러한 프로젝트는 pypproject.toml 를 추가해야 합니다. 그러나 pyproject.toml 를 추가하는 것은 그렇게 많은 작업이 아니며 필요한 경우 빌드 격리를 비활성화하는 명령줄 플래그를 추가할 수 있습니다.

프로젝트의 pip 10에 pyproject.toml 가 없으면 최소한 경고를 표시해야 합니다(어쨌든 PEP 517 지원이 없을 것 같습니다).

@xoviat "조정할 작업이 많지 않을 것"은 이전 버전과의 호환성이 작동하는 방식이 아닙니다. 그렇다면 pip는 지금까지 기본 non-venv 설치 모델로 --user 로 전환했을 것입니다. :)

PEP 517이 진행되는 한 pyproject.toml 파일을 추가 하지 않고 는 패키지 게시자로서 PEP 517에 의존할 수 없으므로 setup.py -only 프로젝트가 PEP 517 지원을 받지 않아도 괜찮습니다. 기본적으로.

경고를 뱉어도 괜찮을까요?

프로젝트 자체나 종속성이 변경되지 않았더라도 현재 잘 작동하는 빌드가 pip가 업그레이드되었다는 이유로 경고를 내뱉기 시작했다면 문제로 볼 것입니다.

PEP 518 및 517은 관련된 모든 게시자가 계속해서 setuptools에만 의존하는 기존 프로젝트를 중단 하지 않도록 의도적으로 설계되었습니다.

pip 가 setuptools 기반 프로젝트의 경우에도 단일 PEP 518 빌드 경로로 다시 통합하는 것을 목표로 하는 것은 의미가 있지만, 그 시간은 격리된 빌드가 릴리스 또는 두 가지 가치의 실제 사용을 본 후 입니다. 그것들을 전혀 지원하지 않는 첫 번째 버전에서.

나는 Donald와 똑같은 말을 했습니다. 이 스레드에 대한 내 이해는 바이너리 전용은 pip 10에 대해 구현할 시간이 없기 때문에 일시적이라는 것입니다. 맞습니까?

네. 정확히.

pip가 setuptools 기반 프로젝트의 경우에도 단일 PEP 518 빌드 경로로 다시 통합하는 것을 목표로 하는 것은 이치에 맞습니다. 그들을 전혀 지원합니다.

+1

2개의 주요 릴리스와 같이 이전 경로를 제거하는 것을 목표로 해야 한다고 생각합니다. pip가 완전하고 적절한 PEP 518 지원을 받으면; 이전 빌드 로직을 더 이상 사용하지 않고 표준 사용 중지 정책에 따라 제거해야 합니다.

나는 Nick의 요약에 동의하고 ...

구현하는 데 필요한 노력의 양이 크게 증가하기 때문입니다.

아니요. 저는 이러한 방식으로 PEP 518을 구현하는 데 큰 장애물이 있다고 생각하지 않습니다. https://github.com/pypa/pip/pull/4799#issuecomment -339219397에 대해 pip 내에서 이것이 어떻게 구현될 수 있는지에 대해 짧은 의견을 남겼습니다.

우리가 하고자 하는 것은 사람들에게 오래된 것에서 새로운 것으로의 깨끗한 전환을 제공하는 것입니다. 따라서 현재 pip 9 설치 로직을 변경하지 않은 상태로 유지해야 합니다. 이는 기본적으로 현재 수행하는 모든 작업을 정확한 방식으로 지원합니다.

아카이브에 pyproject.toml 파일을 넣는 것은 패키지가 새로운 표준을 선택하고 새로운 동작에 대한 지원을 테스트할 용의가 있음을 의미합니다. 격리 및 바이너리 전용 빌드가 있는 빌드 환경을 통과합니다. - 종속성(현재).

아니요. 저는 이러한 방식으로 PEP 518을 구현하는 데 큰 장애물이 있다고 생각하지 않습니다.

여기에서 PEP 517에 대해 논의합니다. 혼란을 드려 죄송합니다.

두 코드 경로를 모두 확인하려면 테스트를 두 번 실행해야 합니다. 아 글쎄, PEP 517은 아마도 연기되었을 것입니다.

IMO,

1. 프로젝트에 pyproject.toml 가 없는 경우 경고는 매우 나쁜 생각처럼 들립니다. 결국, PyPI에 있는 프로젝트의 99%는 현재 pyproject.toml 가 없으며 최종 사용자에게 아무것도 할 수 없다는 경고를 스팸으로 보낼 수 없습니다(프로젝트에 문제를 보고하는 것 외에는 ). 내가 뭔가를 놓치고 있습니까?
2. 나는 PEP 518에서 빌드 격리가 전혀 언급되지 않았다고 생각합니다. 그것은 pip가 지금 한동안 포함하기를 원했던 추가 기능이지만, 동일한 PR이 구현되었다는 우연의 사실을 제외하고는 PEP 518 지원에 묶여 있지 않습니다. 둘 다(AFAIR). 따라서 빌드 격리가 여기에서 문제를 일으키는 경우 처음에는 PEP 518만 사용하고 2단계로 격리를 추가해도 됩니다. 하지만 그 결정은 구현하는 사람들에게 맡기겠습니다.

내가 뭔가를 놓치고 있습니까?

아니요.

처음에는 PEP 518만 사용하고 2단계로 격리를 추가해도 괜찮습니다.

사람들이 격리된 빌드로 전환하도록 하는 좋은 방법이기 때문에 PEP 518을 수행하고 격리를 함께 빌드해야 한다고 생각합니다.

PEP 518이나 PEP 517 모두 격리된 빌드 가 필요 하지 않지만 PEP 517은 건전한 이유로 권장합니다. https://www.python.org/dev/peps/pep-0517/#recommendations -for-build-frontends-non-normative

로컬 바이너리 아티팩트 캐시가 없으면 격리된 빌드 환경은 비실용적이지만 일단 그런 환경 중 하나가 있으면(현재 pip 처럼) 다음과 같은 이유로 훨씬 더 실현 가능합니다.

1. 대부분의 설치에서는 처음부터 소스 빌드를 수행할 필요조차 없습니다.
2. 소스 빌드를 수행해야 하는 경우 일반적으로 캐시에서 빌드 환경을 설정합니다.

동시에, 격리된 빌드 환경 은 게시자의 작업이 조금 더 필요합니다. 이는 버그가 있는 메타데이터가 게시자 의 빌드를 중단시켜 "내 빌드 종속성이 완전히 선언되지 않았습니다"라고 명시적으로 말해야 한다는 것을 의미하기 때문입니다. 빌드를 합니다.

따라서 pyproject.toml 기반 빌드를 처음부터 격리하는 것은 자연스러운 전환 지점을 제공합니다. 왜냐하면 전체 PEP는 런타임 종속성과 별도로 빌드 종속성을 명확하고 일관되게 선언하는 방법을 제공하기 때문입니다. 즉, setup.py 에서 전환하는 사람들은 아마도 그런 종류의 일을 하는 것에 관심이 있기 때문에 그렇게 하는 반면, 새로운 프로젝트를 위해 새로 시작하는 사람들은 패키징 도구로 인해 점프해야 하는 또 다른 고리로 취급할 것입니다. 을 통해.

따라서 코드를 작성하기 전에 확인하고 싶은 몇 가지 사항은 다음과 같습니다.

• PEP 517 지원은 pip 10에 대한 차단기가 아닙니다.
• 핍 10의 PEP 518
  
  
  
  • pyproject.toml 를 통해 선택
  
  
  • 바이너리 전용 빌드 종속성만 지원
  
  
  • 격리된 빌드
  
  

PEP 517은 아직 준비되지 않았기 때문에 pip 10에 대한 차단기가 될 수 없으며 이 시점에서 명확한 경로가 없습니다(앞으로 경로는 있지만 명확하지 않음).

이 스레드를 빠르게 읽은 후뿐 아니라 구현 문제를 요약한 @xoviat 의 의견 에 대한 응답으로 의견과 질문이 있습니다.

첫째, 폭발 가능성이 있는 재귀 문제와 관련하여 일반적으로 모든 재귀 함수는 반복 함수로 "변환"될 수 있습니다. 그 접근 방식이 더 많은 제어를 제공하여 여기에서 도움이 될 수 있는지 궁금합니다.

둘째, Python 내에서 pip 함수를 호출하는 것과 반대로 구매를 포격하는 것은 무엇입니까? 내부 API 함수를 생성/리팩터링할 수 없는 이유가 무엇이든 이를 통해 달성하려는 모든 작업을 수행할 수 있습니까? 이는 호출을 호출할 때 더 많은 유연성을 제공해야 합니다(CLI 매개변수와 비교하여). 이것은 또한 전체 프로세스의 상태를 보다 쉽게 ​​관리할 수 있도록 하여 더 많은 제어를 제공할 수 있습니다.

내부 API 함수를 생성/리팩터링할 수 없는 이유가 무엇이든 이를 통해 달성하려는 모든 작업을 수행할 수 있습니까?

둘째, Python 내에서 pip 함수를 호출하는 것과 반대로 구매를 포격하는 것은 무엇입니까?

그것은 우리가 현재 가지고 있지 않은 시간을 산다. pip 의 출시 일정이 이미 늦어졌습니다.

첫째, 폭발 가능성이 있는 재귀 문제와 관련하여 일반적으로 모든 재귀 함수는 반복 함수로 "변환"될 수 있습니다.

저는 재귀를 반대하는 사람이 아닙니다. 저는 프로세스 재귀를 반대합니다. 100% CPU(Python에서는 20%)를 사용하려는 경우 괜찮다고 생각하지만 궁극적으로 사용자는 작업 관리자를 열고 최대 15개의 프로세스를 종료할 수 있어야 합니다. 나에게 잠재적으로 프로세스 폭발을 일으킬 수 있는 상황은 용납할 수 없습니다.

그렇다고 해서 시간을 버는 이유에 대한 질문에는 답이 되지 않습니다. 동일한 작업을 수행하는 내부 API 함수를 만드는 것이 어려운 이유는 무엇입니까?

어쨌든 쉘링 아웃이 특정 문제를 해결한다면 이 접근 방식을 더 쉽게 만들 수 있는 한 가지 가능성은 필요한 모든 정보를 더 쉽게 전달할 수 있도록 개인/내부 CLI 명령을 일시적으로 노출하는 것입니다(예: 직렬화된 Python 객체일 수도 있습니다). , 등).

그렇다고 해서 시간을 버는 이유에 대한 질문에는 답이 되지 않습니다. 동일한 작업을 수행하는 내부 API 함수를 만드는 것이 어려운 이유는 무엇입니까?

쉽다고 생각하시면 진행하세요. 비꼬는 말이 아닙니다. 모든 문제를 해결할 수 있기 때문에 계속 진행하세요.

쉽지 않은 것 같아요. 왜 어려운지 알기 위해 질문드립니다. (당신이 시간을 절약할 수 있다고 말한 이후로 당신이 이것에 대해 생각했다고 가정합니다.)

pkg_resources 와 같은 위치의 캐시 때문에 일반적으로 하위 프로세스 내부에서 별도의 pip 설치가 필요합니다(틀릴 수 있음).

그렇다고 pip 를 호출해야 하는 것은 아니지만 CLI를 통해 데이터를 직렬화하는 API를 만들고 python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" 를 호출하고 stdout에서 더 많은 데이터를 읽을 수 있습니다. 이러한 API를 사용하여 스택으로 변환하여 pip 호출 pip 호출 pip 호출 pip 호출의 재귀 솔루션을 전환하는 것이 가능합니다(모든 재귀는 스택으로도 설명될 수 있기 때문에), 기본적으로 비공개 API를 만드는 것입니다. 프로세스로 호출됩니다.

나는 여전히 이 스레드를 읽을 계획입니다(최근에 많은 판이 회전했습니다!). 그러나 한 가지 더 중요한 점은: 우리는 실제로 출시 일정이 없으며 어떤 목표 날짜가 아닌 준비가 되면 출시합니다. 우리는 때때로 우리가 언제 출시하고 싶은지에 대한 일반적인 아이디어를 가지고 있지만 그것이 확정된 것은 아닙니다.

궁극적으로 Python에는 상황이 통제 불능 상태가 되지 않도록 최대 재귀 깊이가 있습니다. 우리가 그 접근 방식으로 간다면 그것을 구현해야 할 것입니다.

예, 스택 기반 접근 방식을 사용하면 꽤 깊이 들어가는 것이 매우 효율적입니다(종속성 루프가 할 수 있는 것보다 훨씬 더 깊음, 예를 들어 문자 그대로 모든 패키지에 의존하고 여전히 괜찮을 수 있는 무언가를 가질 수 있음), 가장 중요한 것은 할 일은 루프를 감지하는 것입니다.

루프 감지를 수행하는 상당히 순진하고 쉬운 방법 중 하나는 스택의 항목 수에 상한선을 설정하고 이 제한에 도달하면 반드시 루프 상황에 있고 오류가 발생해야 한다고 말하는 것입니다. 그 단점은 물론 루프가 가능한 한 빨리 감지되지 않고 더 깊은 빌드 종속성 체인이 있는 패키지는 제한이 작동하지 않는다는 것입니다.

일반적으로 더 나은 옵션(스택 기반 접근 방식을 사용하는 경우 전체 스택에 액세스할 수 있기 때문에)은 단순히 스택을 순회하고 설치하려는 항목이 이미 스택의 아무 곳에나 있는지 확인하는 것입니다. 우리가 루프에 빠졌기 때문에 브레이크 아웃 및 오류가 발생했습니다(이 오류는 최종 사용자에게 제공되거나 해결 프로그램에 버블링되어 결국 다른 버전을 시도할 수 있지만 훨씬 느려질 수 있음).

그리고 @cjerdonek 의 질문에 직접 대답하기 위해: 원칙적으로 이것은 어렵지 않습니다 . 문제를 어렵게 만드는 것은 pip 가 현재 작동하는 방식에 포함된 아키텍처 가정이며 각 소스가 빌드되는 세계에서는 더 이상 사실이 아닙니다. 설치 환경에서 직접 실행하는 대신 자체 격리된 빌드 환경을 가져옵니다.

즉, 내부 아키텍처 제한을 넘어 현재 작동 중인 코드를 깨는 위험 없이 pip 의 기존 종속성 관리 논리를 재사용하는 가장 쉬운 방법은 하위 프로세스에서 pip의 다른 인스턴스를 실행하는 것입니다. 의존성 루프를 감지하고 빠져나오지 못하면 빌드를 실행하는 시스템이 포크 폭탄을 터트릴 수 있다는 결과를 제외하고 는 대부분 괜찮습니다.

나는 반복적/스택 기반 접근 방식으로 변환하고 python -c "from pip._internals import coolapithing; coolapithing(sys.stdin.read())" 패턴을 사용하여 내부 pip 함수로 셸링한다는 @dstufft 의 아이디어를 좋아합니다. 토론을 기반으로 했을 때 가장 간단하고 강력해 보입니다.

이에 대한 첫 번째 단계는 예상되는 입력 및 출력(적어도 스케치)이 있는 단일 재귀 Python 함수로 간단한 재귀 접근 방식을 끓인 다음 반복 접근 방식으로 번역/변환할 수 있다고 생각합니다. 그리고 예, 방문 호출의 set 를 유지하여 루핑을 방지할 수 있습니다. 이는 해결하기 쉬운 측면 중 하나인 것 같습니다.

재귀적 접근 방식을 반복적 접근 방식으로 변환하는 방법에 대해 조금 더 살펴보고 생각했습니다. @xoviat 의 PEP 518(PR #4799) 부분 작업은 재귀의 요점을 찾는 데 도움이 되었습니다(일부는 이미 알고 있을 것입니다). 그의 코드 주석에 있습니다.

# TODO: Use single process with recursion handling

여기서 pip install ... 를 호출합니다.

내 생각은 다음과 같은 변경으로 pip install (빌드 종속성용)의 변형으로 해결할 수 있을 것 같습니다.

• 설치에 하위 설치가 필요하지 않은 경우 설치를 수행하십시오.
• 그렇지 않으면 필요한 하위 설치 목록(부분적일 수 있음)과 함께 반환합니다(예: stdout에 쓰는 것이 아직 작동하지 않는 경우 동의한 파일에 정보를 기록).

이러한 방식으로 최상위 루트 프로세스는 빌드 종속성의 트리를 점진적으로 생성할 수 있습니다. 그리고 잎이 발견되는 대로 처리할 수 있습니다. 잎이 처리되면 이전에 잎이 아니었던 노드가 잎이 되는 식입니다. 이 구현을 사용하면 언제든지 하위 프로세스에서 최대 한 번의 pip-install만 발생합니다.

위에서 제안한 것의 약간의 변형은 필요한 pip 명령/하위 프로세스 호출이 후보 설치에 필요한 하위 설치 호출 목록을 반환/내보낼 수 있다는 것입니다( pip get-subinstalls 또는 단순히 pip subinstalls 명령). 위에서 제안한 것과의 유일한 차이점은 이 명령이 보고 정보로 제한된다는 것입니다. 실제로 설치를 수행하지 않습니다. 따라서 구현하는 것이 더 간단하고 테스트하기 쉬울 수 있습니다.

@cjerdonek 나는 그 아이디어에 아무런 문제가 없다고 봅니다. 그러나 궁극적으로 누군가가 그것을 구현해야 하며(내 생각에 @pradyunsg 가 이번 주말에 작업을 할 것이라고 생각합니까?) 항상 그렇듯이 더 많은 어려움이 발견될 수 있습니다.

뭔가 올라왔습니다. 다른 사람이 이것을 데리러 가고 싶다면 나는 없다.
문제. :)

나는 또한 @dstufft 의 아이디어를 좋아합니다.

2017년 10월 29일 일요일 08:47 xoviat, [email protected] 에서 다음과 같이 썼습니다.

@cjerdonek https://github.com/cjerdonek 나는 문제가 없다고 봅니다.
그 생각. 그러나 궁극적으로 누군가가 그것을 구현해야한다고 생각합니다.
@pradyunsg https://github.com/pradyunsg 는 뭔가 작업을 하려고 했습니다
이번 주말?) 그리고 언제나처럼 더 많은 어려움이 발견될 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pip/issues/4802#issuecomment-340234567 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADH7SYImpWgJGg-DzQRcO_9hHfE6ZxEAks5sw-5RgaJpZM4QBdSg
.

다시 돌아와서 @dstufft가 제안한 스택+내부 호출 접근 방식을 계속 진행하시겠습니까?

/ping @ncoghlan @pfmoore @xavfernandez

예, 부탁합니다. 이것을 앞으로 나아가기 위해 무엇이든.

pip 10 릴리스와 관련하여 PEP 517 및 PEP 518의 입장을 요약할 수 있는 사람이 있습니까? 구체적으로:

1. 마스터가 현재 해제 가능한 상태입니까? 마지막으로 PEP 518 지원이 중단되었다고 들었습니다(PEP 518 - #4647과 관련된 릴리스 차단 문제가 하나 이상 열려 있음).
2. PEP 517 및/또는 PEP 518을 사용할 수 있을 때까지 pip 10을 지연시키는 것이 합당한 시간 단위로 작동할 가능성이 있습니까?
3. (1)의 내용을 수정했다고 가정하고 PEP 517/518 없이 pip 10 릴리스를 하시겠습니까? 출시에 대한 헤드업 이메일을 제작하여 사람들이 출시가 임박했음을 알렸습니다. 그리고 거기에는 릴리스하기 좋은 몇 가지 합리적으로 중요한 수정 사항(예: Windows용 인코딩 수정 사항)이 있습니다.

내 느낌은 우리가 릴리스 차단기를 기다리고 있지만 PEP 517/518 지원에 가까워서 pip 10을 차단할 수 없다는 것입니다. 그러나 PEP 518 구현의 일부를 제외하고 는 아무도 #4647에서 작업하고 있다고 생각하지 않습니다.

한 가지 대안은 현재 PEP 518 지원의 제한 사항을 문서화하고 #4647을 릴리스 차단에서 다운그레이드하는 것입니다. 나는 그것이 실행 가능한지 알기 위해 사용 사례에 대해 충분히 알지 못합니다.

방금 이 토론을 보았습니다. 포크 폭탄처럼 작동하기 쉬운 반쯤 구운 초기 구현에 대해 사과하고 시간을 내어 이를 이해하고 더 나은 아이디어를 생각해 낸 모든 분들께 감사드립니다.

FWIW, 빌드 요구 사항을 위해 바퀴를 설치하는 것으로 제한하는 것이 첫 번째 버전에 대해 수용 가능한 절충안이 될 것이라고 생각합니다.

이것은 또한 flit 자체가 빌드 요구 사항이 아니도록 문제를 수정해야 함을 상기시킵니다.

포크 폭탄처럼 작동하기 쉬운 반쯤 구운 초기 구현에 대해 사과합니다.

사과는 필요 없습니다. 내가 말했듯이 첫 번째 시도에서 이러한 문제를 예측할 수 없습니다. 우리가 지금 알고 있는 것을 알면서도 PR을 미루면 이러한 논의가 미뤄졌을 것입니다.

마스터가 현재 해제 가능한 상태입니까?

IIUC, 현재로서는 시스템에 폭탄을 던질 수 있습니다. 그 맞습니까? 그렇다면 그렇지 않다고 생각합니다.

PEP 517 및/또는 PEP 518을 사용할 수 있을 때까지 pip 10을 지연시키는 것이 합당한 시간 단위로 작동할 가능성이 있습니까?

내 생각에 쉬운 (단기) 솔루션은 빌드 종속성을 위해 바퀴로 제한하는 것입니다. 다음주에 한번 해보려고 합니다. 그것이 실현되지 않는다면 마스터에서 현재 PEP 518 지원을 제거하고 10.0.0을 잘라도 괜찮을 것입니다.

PEP 518 구현의 일부를 제외하고는 아무도 #4647에서 작업하고 있다고 생각하지 않습니다.

소스 빌드 종속성이 허용된 PEP 518의 완전한 구현을 의미합니까?

아, 그리고 #4647에 대해 -- 위의 @xoviat 의 설명에 따르면 수정하려면 코드 변경/이동 및 개체의 소유권/가시성(특히 BuildEnvironment )이 필요하며 이는 사소한 일이 아닙니다.

나는 그것을 바퀴로 제한하는 것이 다음 줄을 변경하는 것처럼 간단해야 한다고 생각합니다.

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

에게:

finder.format_control = FormatControl(set(), set([':all:']))

두 번째 필드에는 바이너리로만 찾을 수 있는 패키지 세트가 있으며 ':all:' 는 모든 패키지를 의미하는 특별한 경우가 있습니다.

예. 하지만 그것만으로는 #4647을 해결할 수 없습니다. 또한이 코드 중 어느 것도 가지 않습니다.
해결사를 통해.

2017년 12월 2일 토요일 01:23 Thomas Kluyver [email protected] 에서 다음과 같이 썼습니다.

이것을 바퀴로 제한하는 것은 이것을 변경하는 것만 큼 간단해야한다고 생각합니다.
라인:

https://github.com/pypa/pip/blob/fc6b2c192088737f81259b6446f627f20ce46443/src/pip/_internal/wheel.py#L696

에게:

finder.format_control = FormatControl(set(), set([':all:']))

두 번째 필드에는 바이너리로만 찾을 수 있는 패키지 세트가 있습니다.
모든 패키지를 의미하는 ':all:'의 특별한 경우.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pip/issues/4802#issuecomment-348598368 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADH7SUi0QMS3rr5Iba90XWZmFweGmqeBks5s8FlEgaJpZM4QBdSg
.

맞아요, 다른 문제가 많이 있습니다. 그러나 그것은 가장 시급한 관심사라고 생각하는 포크 ​​폭탄 테러를 방지해야 합니다.

누군가가 내 원래 PR을 인수하려는 경우("PEP 518 문제 수정"),
빌드 격리가 되지 않도록 변경하는 것이 어렵지 않아야 합니다.
pyproject.toml 없이 활성화됩니다. 병합되지 않은 원래 이유
소스에서 종속성을 설치하는 지원을 중단했다는 것입니다.
PEP 518. 그러나 이제 사람들은 PEP 518이
pip 10에 전혀 포함되지 않은 경우 해당 PR을 더 잘 수용할 수 있습니다. 나
개인적으로 그것을 옹호할 시간이 없지만 다른 사람들을 막을 수는 없습니다.
몇 줄만 변경하면 되므로
(PEP 518 테스트에 실패하는 것을 제외하고).

사실, 더 나은 판단에 반하여 pip 개발자가 내 조건에 동의한다면 곧 PEP 517과 518을 모두 구현할 용의가 있습니다.

1. 종속성은 처음에 바퀴에서만 발생합니다.
2. pip는 결국 제거되지만 초기에는 내부 빌드 백엔드가 있습니다.

1에 문제가 없습니다. 나는 2에 ​​대해 어느 쪽이든 선호하지 않습니다.

2017년 12월 3일 일요일 02:36 xoviat [email protected] 에서 다음과 같이 썼습니다.

사실, 더 나은 판단에 반해 나는 두 PEP를 모두 구현할 용의가 있습니다.
pip 개발자가 내 조건에 동의하면 곧 517 및 518:

1. 종속성은 처음에 바퀴에서만 발생합니다.
2. pip는 초기에 내부 빌드 백엔드를 갖습니다.
   결국 제거됩니다

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pip/issues/4802#issuecomment-348720096 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADH7ST6riptZkYMap5Z5SstRf-VmE7eAks5s8bu5gaJpZM4QBdSg
.

참고로 조건은 임의적이지 않지만 초기 구현을 가능하게 하기 위한 것입니다. @pfmoore 이거 괜찮나요?

나는 "나의 더 나은 판단에 반하여 ... 내 조건에 동의합니다"라는 제안의 어조에 특히 편하지 않습니다. 다른 pip 개발자들이 이 제안을 기꺼이 받아들인다면 이의를 제기하지 않겠지만 개인적으로 구현 세부 사항에 대한 전체 토론을 다시 시작할 시간이 없습니다. 기본적으로, 나는 이것에 대해 @dstufft 와 @xavfernandez 에게 맡길 것입니다( @pradyunsg 는 이미 그의 견해를 제시했습니다).

제안의 어조는 초기 구현 방식에 대한 근본적인 불일치로 인해 구현 방법이 폐쇄되었기 때문입니다. 나는 다른 구현 토론으로 넘어가기보다는 지금 원칙에 동의하고 싶습니다.

나는 또한 톤이 매우 편안하지 않다는 것을 진술할 것입니다.
그 톤이 사용된 이유에 대해 설명할 시간이나 에너지가 없습니다.
등. 내 끝에서 간결한 대답에 대한 동일한 이유.

아마도 언급할 가치가 있을 것입니다. 저는 바이너리만 빌드 종속성을
장기간이 아닌 첫 번째 구현입니다. 이것은 적용되지 않습니다
런타임 종속성
논의).

2017년 12월 3일 일요일, 23:37 xoviat, [email protected] 에서 다음과 같이 썼습니다.

제안의 어조는 방법이 있기 때문에 있는 그대로입니다.
에 대한 근본적인 불일치로 인해 구현이 중단되었습니다.
초기 구현은 다음과 같습니다. 나는 차라리 동의한다.
원칙은 이제 다른 구현 토론으로 넘어갑니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.

이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/pypa/pip/issues/4802#issuecomment-348802032 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ADH7ScUh-BveonoTxZ5FkkeSynFvoLb8ks5s8uNRgaJpZM4QBdSg
.

솔직히 말해서, 이것은 pip 10에 이러한 기능을 포함하는 것과 관련이 없기 때문에 게시물의 어조에 대해 더 논의하기 위해 다른 사람의 시간을 효과적으로 사용하지 않을 수 있습니다. 그러나 내 조건이 @pfmoore ( 아무도 여기에 시간을 지불하지 않는다는 점을 감안할 때 그러한 보증을 할 수 없다고 표시한 사람), @dstufft 또는 @xavfernandez.

다시 말하지만 조건은 제 개인적인 의견이 아니라 구현 중심입니다. 이러한 조건을 완화하면 구현을 약속할 수 없으므로 PR을 준비하는 데 시간을 할애하고 사람들이 diff를 읽고 "오, 이 줄이 왜 여기에 있습니까?"라고 묻는 의미가 없습니다. 그런 다음 "오, 병합할 수 없습니까?" PR의 목적이 정확히 무엇인지에 대한 오해가 있었기 때문입니다.

다시 톤에 동의했습니다. 내 요점은 단순히 변경 사항[1]을 병합하지 않을 것이므로 여기서 내 견해는 그다지 중요하지 않습니다.

[1] 분명히, 나는 구현을 보지 않고 말하는 것이므로 내 이유가 코드 품질에 대한 우려와 관련이 없다는 것이 분명하기를 바랍니다. 코드를 충분히 이해했는지 확인할 시간이 없기 때문입니다. 기본적으로 병합할 의사가 있습니다.

@xoviat 위에서 논의한 반복적 접근 방식과 재귀적 접근 방식에 대한 구현 계획은 무엇입니까?

또한 명확히 하기 위해 병합할 수 있는 PEP 517 및 518의 부분 구현을 먼저 완료한 다음 병합할 수 있는 전체 구현을 완료한다는 말씀이십니까? 아니면 부분적인 구현만 하겠다고 말씀하시는 건가요, 아니면 병합이 불가능할 수도 있는 초기 단계를 통해 전체 구현을 하겠다고 말씀하시는 건가요? (나는 부분적으로 귀하의 의견 에서 "처음에"와 "결국"이 의미하는 바를 더 잘 이해하려고 노력하고 있습니다.)

첫 번째 조건은 전체 재귀 문제를 제거합니다.

또한 명확히 하기 위해 병합할 수 있는 PEP 517 및 518의 부분 구현을 먼저 완료한 다음 병합할 수 있는 전체 구현을 완료한다는 말씀이십니까?

내가 말하고자 하는 것은 부분 구현을 완료할 것이라는 것입니다. 이것은 사용 사례의 95%에서 작동합니다. 특히 종속성에 바퀴가 있고(지금은 매우 일반적임) 많은 Linux/windows/OSX 플랫폼(대다수 사용자)에 있는 경우에 그렇습니다.

완전한 구현은 아닙니다. 그러나 병합 불가능한 PR을 얻는 방법은 표준을 준수하거나 준수하지 않는 "전부 아니면 전무" 접근 방식을 시도하는 것입니다.

전체 구현 에는 각각 별도의 PR이 필요한 상당히 불쾌한 문제를 정렬해야 한다는 점을 염두에 두십시오. [1]

[1] https://github.com/btc1/bitcoin/pull/11#issuecomment -313843216

이제 이 문제를 닫겠습니다. 빌드 종속성으로 휠만 지원하는 pip 10의 PEP 518에 대한 예비 지원이 있습니다. 완전한 지원에 대해 논의하기 위한 새로운 문제와 PEP 517 지원에 대한 또 다른 문제를 열겠습니다(관련된 경우 여기에서 인용).

통찰력과 도움을 주신 @ncoghlan @rgommers @cjerdonek 에게 감사드립니다. PEP 518의 초기 구현에 대해 @takluyver 에게 감사합니다. 이러한 변경을 구현하는 데 도움을 준 @xoviat (현재 @ghost 가 됨)에게 감사합니다. 현재 지원을 개선하는 데 도움을 주신 @benoit-pierre에게 감사드립니다.

추신: 100번째 댓글! :따다:

이 스레드는 닫힌 후 최근 활동이 없었기 때문에 자동으로 잠겼습니다. 관련 버그에 대한 새 문제를 여십시오.